<!doctype html><html lang="en">
 <head>
  <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  <meta content="width=device-width, initial-scale=1, shrink-to-fit=no" name="viewport">
  <title>P0907R2: Signed Integers are Two’s Complement</title>
<style data-fill-with="stylesheet">/******************************************************************************
 *                   Style sheet for the W3C specifications                   *
 *
 * Special classes handled by this style sheet include:
 *
 * Indices
 *   - .toc for the Table of Contents (<ol class="toc">)
 *     + <span class="secno"> for the section numbers
 *   - #toc for the Table of Contents (<nav id="toc">)
 *   - ul.index for Indices (<a href="#ref">term</a><span>, in §N.M</span>)
 *   - table.index for Index Tables (e.g. for properties or elements)
 *
 * Structural Markup
 *   - table.data for general data tables
 *     -> use 'scope' attribute, <colgroup>, <thead>, and <tbody> for best results !
 *     -> use <table class='complex data'> for extra-complex tables
 *     -> use <td class='long'> for paragraph-length cell content
 *     -> use <td class='pre'> when manual line breaks/indentation would help readability
 *   - dl.switch for switch statements
 *   - ol.algorithm for algorithms (helps to visualize nesting)
 *   - .figure and .caption (HTML4) and figure and figcaption (HTML5)
 *     -> .sidefigure for right-floated figures
 *   - ins/del
 *
 * Code
 *   - pre and code
 *
 * Special Sections
 *   - .note       for informative notes             (div, p, span, aside, details)
 *   - .example    for informative examples          (div, p, pre, span)
 *   - .issue      for issues                        (div, p, span)
 *   - .assertion  for assertions                    (div, p, span)
 *   - .advisement for loud normative statements     (div, p, strong)
 *   - .annoying-warning for spec obsoletion notices (div, aside, details)
 *
 * Definition Boxes
 *   - pre.def   for WebIDL definitions
 *   - table.def for tables that define other entities (e.g. CSS properties)
 *   - dl.def    for definition lists that define other entitles (e.g. HTML elements)
 *
 * Numbering
 *   - .secno for section numbers in .toc and headings (<span class='secno'>3.2</span>)
 *   - .marker for source-inserted example/figure/issue numbers (<span class='marker'>Issue 4</span>)
 *   - ::before styled for CSS-generated issue/example/figure numbers:
 *     -> Documents wishing to use this only need to add
 *        figcaption::before,
 *        .caption::before { content: "Figure "  counter(figure) " ";  }
 *        .example::before { content: "Example " counter(example) " "; }
 *        .issue::before   { content: "Issue "   counter(issue) " ";   }
 *
 * Header Stuff (ignore, just don't conflict with these classes)
 *   - .head for the header
 *   - .copyright for the copyright
 *
 * Miscellaneous
 *   - .overlarge for things that should be as wide as possible, even if
 *     that overflows the body text area. This can be used on an item or
 *     on its container, depending on the effect desired.
 *     Note that this styling basically doesn't help at all when printing,
 *     since A4 paper isn't much wider than the max-width here.
 *     It's better to design things to fit into a narrower measure if possible.
 *   - js-added ToC jump links (see fixup.js)
 *
 ******************************************************************************/

/******************************************************************************/
/*                                   Body                                     */
/******************************************************************************/

	body {
		counter-reset: example figure issue;

		/* Layout */
		max-width: 50em;               /* limit line length to 50em for readability   */
		margin: 0 auto;                /* center text within page                     */
		padding: 1.6em 1.5em 2em 50px; /* assume 16px font size for downlevel clients */
		padding: 1.6em 1.5em 2em calc(26px + 1.5em); /* leave space for status flag     */

		/* Typography */
		line-height: 1.5;
		font-family: sans-serif;
		widows: 2;
		orphans: 2;
		word-wrap: break-word;
		overflow-wrap: break-word;
		hyphens: auto;

		/* Colors */
		color: black;
		background: white top left fixed no-repeat;
		background-size: 25px auto;
	}


/******************************************************************************/
/*                         Front Matter & Navigation                          */
/******************************************************************************/

/** Header ********************************************************************/

	div.head { margin-bottom: 1em }
	div.head hr { border-style: solid; }

	div.head h1 {
		font-weight: bold;
		margin: 0 0 .1em;
		font-size: 220%;
	}

	div.head h2 { margin-bottom: 1.5em;}

/** W3C Logo ******************************************************************/

	.head .logo {
		float: right;
		margin: 0.4rem 0 0.2rem .4rem;
	}

	.head img[src*="logos/W3C"] {
		display: block;
		border: solid #1a5e9a;
		border-width: .65rem .7rem .6rem;
		border-radius: .4rem;
		background: #1a5e9a;
		color: white;
		font-weight: bold;
	}

	.head a:hover > img[src*="logos/W3C"],
	.head a:focus > img[src*="logos/W3C"] {
		opacity: .8;
	}

	.head a:active > img[src*="logos/W3C"] {
		background: #c00;
		border-color: #c00;
	}

	/* see also additional rules in Link Styling section */

/** Copyright *****************************************************************/

	p.copyright,
	p.copyright small { font-size: small }

/** Back to Top / ToC Toggle **************************************************/

	@media print {
		#toc-nav {
			display: none;
		}
	}
	@media not print {
		#toc-nav {
			position: fixed;
			z-index: 2;
			bottom: 0; left: 0;
			margin: 0;
			min-width: 1.33em;
			border-top-right-radius: 2rem;
			box-shadow: 0 0 2px;
			font-size: 1.5em;
			color: black;
		}
		#toc-nav > a {
			display: block;
			white-space: nowrap;

			height: 1.33em;
			padding: .1em 0.3em;
			margin: 0;

			background: white;
			box-shadow: 0 0 2px;
			border: none;
			border-top-right-radius: 1.33em;
			background: white;
		}
		#toc-nav > #toc-jump {
			padding-bottom: 2em;
			margin-bottom: -1.9em;
		}

		#toc-nav > a:hover,
		#toc-nav > a:focus {
			background: #f8f8f8;
		}
		#toc-nav > a:not(:hover):not(:focus) {
			color: #707070;
		}

		/* statusbar gets in the way on keyboard focus; remove once browsers fix */
		#toc-nav > a[href="#toc"]:not(:hover):focus:last-child {
			padding-bottom: 1.5rem;
		}

		#toc-nav:not(:hover) > a:not(:focus) > span + span {
			/* Ideally this uses :focus-within on #toc-nav */
			display: none;
		}
		#toc-nav > a > span + span {
			padding-right: 0.2em;
		}

		#toc-toggle-inline {
			vertical-align: 0.05em;
			font-size: 80%;
			color: gray;
			color: hsla(203,20%,40%,.7);
			border-style: none;
			background: transparent;
			position: relative;
		}
		#toc-toggle-inline:hover:not(:active),
		#toc-toggle-inline:focus:not(:active) {
			text-shadow: 1px 1px silver;
			top: -1px;
			left: -1px;
		}

		#toc-nav :active {
			color: #C00;
		}
	}

/** ToC Sidebar ***************************************************************/

	/* Floating sidebar */
	@media screen {
		body.toc-sidebar #toc {
			position: fixed;
			top: 0; bottom: 0;
			left: 0;
			width: 23.5em;
			max-width: 80%;
			max-width: calc(100% - 2em - 26px);
			overflow: auto;
			padding: 0 1em;
			padding-left: 42px;
			padding-left: calc(1em + 26px);
			background: inherit;
			background-color: #f7f8f9;
			z-index: 1;
			box-shadow: -.1em 0 .25em rgba(0,0,0,.1) inset;
		}
		body.toc-sidebar #toc h2 {
			margin-top: .8rem;
			font-variant: small-caps;
			font-variant: all-small-caps;
			text-transform: lowercase;
			font-weight: bold;
			color: gray;
			color: hsla(203,20%,40%,.7);
		}
		body.toc-sidebar #toc-jump:not(:focus) {
			width: 0;
			height: 0;
			padding: 0;
			position: absolute;
			overflow: hidden;
		}
	}
	/* Hide main scroller when only the ToC is visible anyway */
	@media screen and (max-width: 28em) {
		body.toc-sidebar {
			overflow: hidden;
		}
	}

	/* Sidebar with its own space */
	@media screen and (min-width: 78em) {
		body:not(.toc-inline) #toc {
			position: fixed;
			top: 0; bottom: 0;
			left: 0;
			width: 23.5em;
			overflow: auto;
			padding: 0 1em;
			padding-left: 42px;
			padding-left: calc(1em + 26px);
			background: inherit;
			background-color: #f7f8f9;
			z-index: 1;
			box-shadow: -.1em 0 .25em rgba(0,0,0,.1) inset;
		}
		body:not(.toc-inline) #toc h2 {
			margin-top: .8rem;
			font-variant: small-caps;
			font-variant: all-small-caps;
			text-transform: lowercase;
			font-weight: bold;
			color: gray;
			color: hsla(203,20%,40%,.7);
		}

		body:not(.toc-inline) {
			padding-left: 29em;
		}
		/* See also Overflow section at the bottom */

		body:not(.toc-inline) #toc-jump:not(:focus) {
			width: 0;
			height: 0;
			padding: 0;
			position: absolute;
			overflow: hidden;
		}
	}
	@media screen and (min-width: 90em) {
		body:not(.toc-inline) {
			margin: 0 4em;
		}
	}

/******************************************************************************/
/*                                Sectioning                                  */
/******************************************************************************/

/** Headings ******************************************************************/

	h1, h2, h3, h4, h5, h6, dt {
		page-break-after: avoid;
		page-break-inside: avoid;
		font: 100% sans-serif;   /* Reset all font styling to clear out UA styles */
		font-family: inherit;    /* Inherit the font family. */
		line-height: 1.2;        /* Keep wrapped headings compact */
		hyphens: manual;         /* Hyphenated headings look weird */
	}

	h2, h3, h4, h5, h6 {
		margin-top: 3rem;
	}

	h1, h2, h3 {
		color: #005A9C;
		background: transparent;
	}

	h1 { font-size: 170%; }
	h2 { font-size: 140%; }
	h3 { font-size: 120%; }
	h4 { font-weight: bold; }
	h5 { font-style: italic; }
	h6 { font-variant: small-caps; }
	dt { font-weight: bold; }

/** Subheadings ***************************************************************/

	h1 + h2,
	#subtitle {
		/* #subtitle is a subtitle in an H2 under the H1 */
		margin-top: 0;
	}
	h2 + h3,
	h3 + h4,
	h4 + h5,
	h5 + h6 {
		margin-top: 1.2em; /* = 1 x line-height */
	}

/** Section divider ***********************************************************/

	:not(.head) > hr {
		font-size: 1.5em;
		text-align: center;
		margin: 1em auto;
		height: auto;
		border: transparent solid 0;
		background: transparent;
	}
	:not(.head) > hr::before {
		content: "\2727\2003\2003\2727\2003\2003\2727";
	}

/******************************************************************************/
/*                            Paragraphs and Lists                            */
/******************************************************************************/

	p {
		margin: 1em 0;
	}

	dd > p:first-child,
	li > p:first-child {
		margin-top: 0;
	}

	ul, ol {
		margin-left: 0;
		padding-left: 2em;
	}

	li {
		margin: 0.25em 0 0.5em;
		padding: 0;
	}

	dl dd {
		margin: 0 0 .5em 2em;
	}

	.head dd + dd { /* compact for header */
		margin-top: -.5em;
	}

	/* Style for algorithms */
	ol.algorithm ol:not(.algorithm),
	.algorithm > ol ol:not(.algorithm) {
	 border-left: 0.5em solid #DEF;
	}

	/* Put nice boxes around each algorithm. */
	[data-algorithm]:not(.heading) {
	  padding: .5em;
	  border: thin solid #ddd; border-radius: .5em;
	  margin: .5em calc(-0.5em - 1px);
	}
	[data-algorithm]:not(.heading) > :first-child {
	  margin-top: 0;
	}
	[data-algorithm]:not(.heading) > :last-child {
	  margin-bottom: 0;
	}

	/* Style for switch/case <dl>s */
	dl.switch > dd > ol.only,
	dl.switch > dd > .only > ol {
	 margin-left: 0;
	}
	dl.switch > dd > ol.algorithm,
	dl.switch > dd > .algorithm > ol {
	 margin-left: -2em;
	}
	dl.switch {
	 padding-left: 2em;
	}
	dl.switch > dt {
	 text-indent: -1.5em;
	 margin-top: 1em;
	}
	dl.switch > dt + dt {
	 margin-top: 0;
	}
	dl.switch > dt::before {
	 content: '\21AA';
	 padding: 0 0.5em 0 0;
	 display: inline-block;
	 width: 1em;
	 text-align: right;
	 line-height: 0.5em;
	}

/** Terminology Markup ********************************************************/


/******************************************************************************/
/*                                 Inline Markup                              */
/******************************************************************************/

/** Terminology Markup ********************************************************/
	dfn   { /* Defining instance */
		font-weight: bolder;
	}
	a > i { /* Instance of term */
		font-style: normal;
	}
	dt dfn code, code.idl {
		font-size: medium;
	}
	dfn var {
		font-style: normal;
	}

/** Change Marking ************************************************************/

	del { color: red;  text-decoration: line-through; }
	ins { color: #080; text-decoration: underline;    }

/** Miscellaneous improvements to inline formatting ***************************/

	sup {
		vertical-align: super;
		font-size: 80%
	}

/******************************************************************************/
/*                                    Code                                    */
/******************************************************************************/

/** General monospace/pre rules ***********************************************/

	pre, code, samp {
		font-family: Menlo, Consolas, "DejaVu Sans Mono", Monaco, monospace;
		font-size: .9em;
		page-break-inside: avoid;
		hyphens: none;
		text-transform: none;
	}
	pre code,
	code code {
		font-size: 100%;
	}

	pre {
		margin-top: 1em;
		margin-bottom: 1em;
		overflow: auto;
	}

/** Inline Code fragments *****************************************************/

  /* Do something nice. */

/******************************************************************************/
/*                                    Links                                   */
/******************************************************************************/

/** General Hyperlinks ********************************************************/

	/* We hyperlink a lot, so make it less intrusive */
	a[href] {
		color: #034575;
		text-decoration: none;
		border-bottom: 1px solid #707070;
		/* Need a bit of extending for it to look okay */
		padding: 0 1px 0;
		margin: 0 -1px 0;
	}
	a:visited {
		border-bottom-color: #BBB;
	}

	/* Use distinguishing colors when user is interacting with the link */
	a[href]:focus,
	a[href]:hover {
		background: #f8f8f8;
		background: rgba(75%, 75%, 75%, .25);
		border-bottom-width: 3px;
		margin-bottom: -2px;
	}
	a[href]:active {
		color: #C00;
		border-color: #C00;
	}

	/* Backout above styling for W3C logo */
	.head .logo,
	.head .logo a {
		border: none;
		text-decoration: none;
		background: transparent;
	}

/******************************************************************************/
/*                                    Images                                  */
/******************************************************************************/

	img {
		border-style: none;
	}

	/* For autogen numbers, add
	   .caption::before, figcaption::before { content: "Figure " counter(figure) ". "; }
	*/

	figure, .figure, .sidefigure {
		page-break-inside: avoid;
		text-align: center;
		margin: 2.5em 0;
	}
	.figure img,    .sidefigure img,    figure img,
	.figure object, .sidefigure object, figure object {
		max-width: 100%;
		margin: auto;
	}
	.figure pre, .sidefigure pre, figure pre {
		text-align: left;
		display: table;
		margin: 1em auto;
	}
	.figure table, figure table {
		margin: auto;
	}
	@media screen and (min-width: 20em) {
		.sidefigure {
			float: right;
			width: 50%;
			margin: 0 0 0.5em 0.5em
		}
	}
	.caption, figcaption, caption {
		font-style: italic;
		font-size: 90%;
	}
	.caption::before, figcaption::before, figcaption > .marker {
		font-weight: bold;
	}
	.caption, figcaption {
		counter-increment: figure;
	}

	/* DL list is indented 2em, but figure inside it is not */
	dd > .figure, dd > figure { margin-left: -2em }

/******************************************************************************/
/*                             Colored Boxes                                  */
/******************************************************************************/

	.issue, .note, .example, .assertion, .advisement, blockquote {
		padding: .5em;
		border: .5em;
		border-left-style: solid;
		page-break-inside: avoid;
	}
	span.issue, span.note {
		padding: .1em .5em .15em;
		border-right-style: solid;
	}

	.issue,
	.note,
	.example,
	.advisement,
	.assertion,
	blockquote {
		margin: 1em auto;
	}
	.note  > p:first-child,
	.issue > p:first-child,
	blockquote > :first-child {
		margin-top: 0;
	}
	blockquote > :last-child {
		margin-bottom: 0;
	}

/** Blockquotes ***************************************************************/

	blockquote {
		border-color: silver;
	}

/** Open issue ****************************************************************/

	.issue {
		border-color: #E05252;
		background: #FBE9E9;
		counter-increment: issue;
		overflow: auto;
	}
	.issue::before, .issue > .marker {
		text-transform: uppercase;
		color: #AE1E1E;
		padding-right: 1em;
		text-transform: uppercase;
	}
	/* Add .issue::before { content: "Issue " counter(issue) " "; } for autogen numbers,
	   or use class="marker" to mark up the issue number in source. */

/** Example *******************************************************************/

	.example {
		border-color: #E0CB52;
		background: #FCFAEE;
		counter-increment: example;
		overflow: auto;
		clear: both;
	}
	.example::before, .example > .marker {
		text-transform: uppercase;
		color: #827017;
		min-width: 7.5em;
		display: block;
	}
	/* Add .example::before { content: "Example " counter(example) " "; } for autogen numbers,
	   or use class="marker" to mark up the example number in source. */

/** Non-normative Note ********************************************************/

	.note {
		border-color: #52E052;
		background: #E9FBE9;
		overflow: auto;
	}

	.note::before, .note > .marker,
	details.note > summary::before,
	details.note > summary > .marker {
		text-transform: uppercase;
		display: block;
		color: hsl(120, 70%, 30%);
	}
	/* Add .note::before { content: "Note"; } for autogen label,
	   or use class="marker" to mark up the label in source. */

	details.note > summary {
		display: block;
		color: hsl(120, 70%, 30%);
	}
	details.note[open] > summary {
		border-bottom: 1px silver solid;
	}

/** Assertion Box *************************************************************/
	/*  for assertions in algorithms */

	.assertion {
		border-color: #AAA;
		background: #EEE;
	}

/** Advisement Box ************************************************************/
	/*  for attention-grabbing normative statements */

	.advisement {
		border-color: orange;
		border-style: none solid;
		background: #FFEECC;
	}
	strong.advisement {
		display: block;
		text-align: center;
	}
	.advisement > .marker {
		color: #B35F00;
	}

/** Spec Obsoletion Notice ****************************************************/
	/* obnoxious obsoletion notice for older/abandoned specs. */

	details {
		display: block;
	}
	summary {
		font-weight: bolder;
	}

	.annoying-warning:not(details),
	details.annoying-warning:not([open]) > summary,
	details.annoying-warning[open] {
		background: #fdd;
		color: red;
		font-weight: bold;
		padding: .75em 1em;
		border: thick red;
		border-style: solid;
		border-radius: 1em;
	}
	.annoying-warning :last-child {
		margin-bottom: 0;
	}

@media not print {
	details.annoying-warning[open] {
		position: fixed;
		left: 1em;
		right: 1em;
		bottom: 1em;
		z-index: 1000;
	}
}

	details.annoying-warning:not([open]) > summary {
		text-align: center;
	}

/** Entity Definition Boxes ***************************************************/

	.def {
		padding: .5em 1em;
		background: #DEF;
		margin: 1.2em 0;
		border-left: 0.5em solid #8CCBF2;
	}

/******************************************************************************/
/*                                    Tables                                  */
/******************************************************************************/

	th, td {
		text-align: left;
		text-align: start;
	}

/** Property/Descriptor Definition Tables *************************************/

	table.def {
		/* inherits .def box styling, see above */
		width: 100%;
		border-spacing: 0;
	}

	table.def td,
	table.def th {
		padding: 0.5em;
		vertical-align: baseline;
		border-bottom: 1px solid #bbd7e9;
	}

	table.def > tbody > tr:last-child th,
	table.def > tbody > tr:last-child td {
		border-bottom: 0;
	}

	table.def th {
		font-style: italic;
		font-weight: normal;
		padding-left: 1em;
		width: 3em;
	}

	/* For when values are extra-complex and need formatting for readability */
	table td.pre {
		white-space: pre-wrap;
	}

	/* A footnote at the bottom of a def table */
	table.def           td.footnote {
		padding-top: 0.6em;
	}
	table.def           td.footnote::before {
		content: " ";
		display: block;
		height: 0.6em;
		width: 4em;
		border-top: thin solid;
	}

/** Data tables (and properly marked-up index tables) *************************/
	/*
		 <table class="data"> highlights structural relationships in a table
		 when correct markup is used (e.g. thead/tbody, th vs. td, scope attribute)

		 Use class="complex data" for particularly complicated tables --
		 (This will draw more lines: busier, but clearer.)

		 Use class="long" on table cells with paragraph-like contents
		 (This will adjust text alignment accordingly.)
		 Alternately use class="longlastcol" on tables, to have the last column assume "long".
	*/

	table {
		word-wrap: normal;
		overflow-wrap: normal;
		hyphens: manual;
	}

	table.data,
	table.index {
		margin: 1em auto;
		border-collapse: collapse;
		border: hidden;
		width: 100%;
	}
	table.data caption,
	table.index caption {
		max-width: 50em;
		margin: 0 auto 1em;
	}

	table.data td,  table.data th,
	table.index td, table.index th {
		padding: 0.5em 1em;
		border-width: 1px;
		border-color: silver;
		border-top-style: solid;
	}

	table.data thead td:empty {
		padding: 0;
		border: 0;
	}

	table.data  thead,
	table.index thead,
	table.data  tbody,
	table.index tbody {
		border-bottom: 2px solid;
	}

	table.data colgroup,
	table.index colgroup {
		border-left: 2px solid;
	}

	table.data  tbody th:first-child,
	table.index tbody th:first-child  {
		border-right: 2px solid;
		border-top: 1px solid silver;
		padding-right: 1em;
	}

	table.data th[colspan],
	table.data td[colspan] {
		text-align: center;
	}

	table.complex.data th,
	table.complex.data td {
		border: 1px solid silver;
		text-align: center;
	}

	table.data.longlastcol td:last-child,
	table.data td.long {
	 vertical-align: baseline;
	 text-align: left;
	}

	table.data img {
		vertical-align: middle;
	}


/*
Alternate table alignment rules

	table.data,
	table.index {
		text-align: center;
	}

	table.data  thead th[scope="row"],
	table.index thead th[scope="row"] {
		text-align: right;
	}

	table.data  tbody th:first-child,
	table.index tbody th:first-child  {
		text-align: right;
	}

Possible extra rowspan handling

	table.data  tbody th[rowspan]:not([rowspan='1']),
	table.index tbody th[rowspan]:not([rowspan='1']),
	table.data  tbody td[rowspan]:not([rowspan='1']),
	table.index tbody td[rowspan]:not([rowspan='1']) {
		border-left: 1px solid silver;
	}

	table.data  tbody th[rowspan]:first-child,
	table.index tbody th[rowspan]:first-child,
	table.data  tbody td[rowspan]:first-child,
	table.index tbody td[rowspan]:first-child{
		border-left: 0;
		border-right: 1px solid silver;
	}
*/

/******************************************************************************/
/*                                  Indices                                   */
/******************************************************************************/


/** Table of Contents *********************************************************/

	.toc a {
		/* More spacing; use padding to make it part of the click target. */
		padding-top: 0.1rem;
		/* Larger, more consistently-sized click target */
		display: block;
		/* Reverse color scheme */
		color: black;
		border-color: #3980B5;
		border-bottom-width: 3px !important;
		margin-bottom: 0px !important;
	}
	.toc a:visited {
		border-color: #054572;
	}
	.toc a:not(:focus):not(:hover) {
		/* Allow colors to cascade through from link styling */
		border-bottom-color: transparent;
	}

	.toc, .toc ol, .toc ul, .toc li {
		list-style: none; /* Numbers must be inlined into source */
		/* because generated content isn't search/selectable and markers can't do multilevel yet */
		margin:  0;
		padding: 0;
		line-height: 1.1rem; /* consistent spacing */
	}

	/* ToC not indented until third level, but font style & margins show hierarchy */
	.toc > li             { font-weight: bold;   }
	.toc > li li          { font-weight: normal; }
	.toc > li li li       { font-size:   95%;    }
	.toc > li li li li    { font-size:   90%;    }
	.toc > li li li li .secno { font-size: 85%; }
	.toc > li li li li li { font-size:   85%;    }
	.toc > li li li li li .secno { font-size: 100%; }

	/* @supports not (display:grid) { */
		.toc > li             { margin: 1.5rem 0;    }
		.toc > li li          { margin: 0.3rem 0;    }
		.toc > li li li       { margin-left: 2rem;   }

		/* Section numbers in a column of their own */
		.toc .secno {
			float: left;
			width: 4rem;
			white-space: nowrap;
		}

		.toc li {
			clear: both;
		}

		:not(li) > .toc              { margin-left:  5rem; }
		.toc .secno                  { margin-left: -5rem; }
		.toc > li li li .secno       { margin-left: -7rem; }
		.toc > li li li li .secno    { margin-left: -9rem; }
		.toc > li li li li li .secno { margin-left: -11rem; }

		/* Tighten up indentation in narrow ToCs */
		@media (max-width: 30em) {
			:not(li) > .toc              { margin-left:  4rem; }
			.toc .secno                  { margin-left: -4rem; }
			.toc > li li li              { margin-left:  1rem; }
			.toc > li li li .secno       { margin-left: -5rem; }
			.toc > li li li li .secno    { margin-left: -6rem; }
			.toc > li li li li li .secno { margin-left: -7rem; }
		}
	/* } */

	@supports (display:grid) and (display:contents) {
		/* Use #toc over .toc to override non-@supports rules. */
		#toc {
			display: grid;
			align-content: start;
			grid-template-columns: auto 1fr;
			grid-column-gap: 1rem;
			column-gap: 1rem;
			grid-row-gap: .6rem;
			row-gap: .6rem;
		}
		#toc h2 {
			grid-column: 1 / -1;
			margin-bottom: 0;
		}
		#toc ol,
		#toc li,
		#toc a {
			display: contents;
			/* Switch <a> to subgrid when supported */
		}
		#toc span {
			margin: 0;
		}
		#toc > .toc > li > a > span {
			/* The spans of the top-level list,
			   comprising the first items of each top-level section. */
			margin-top: 1.1rem;
		}
		#toc#toc .secno { /* Ugh, need more specificity to override base.css */
			grid-column: 1;
			width: auto;
			margin-left: 0;
		}
		#toc .content {
			grid-column: 2;
			width: auto;
			margin-right: 1rem;
		}
		#toc .content:hover {
			background: rgba(75%, 75%, 75%, .25);
			border-bottom: 3px solid #054572;
			margin-bottom: -3px;
		}
		#toc li li li .content {
			margin-left: 1rem;
		}
		#toc li li li li .content {
			margin-left: 2rem;
		}
	}


/** Index *********************************************************************/

	/* Index Lists: Layout */
	ul.index       { margin-left: 0; columns: 15em; text-indent: 1em hanging; }
	ul.index li    { margin-left: 0; list-style: none; break-inside: avoid; }
	ul.index li li { margin-left: 1em }
	ul.index dl    { margin-top: 0; }
	ul.index dt    { margin: .2em 0 .2em 20px;}
	ul.index dd    { margin: .2em 0 .2em 40px;}
	/* Index Lists: Typography */
	ul.index ul,
	ul.index dl { font-size: smaller; }
	@media not print {
		ul.index li span {
			white-space: nowrap;
			color: transparent; }
		ul.index li a:hover + span,
		ul.index li a:focus + span {
			color: #707070;
		}
	}

/** Index Tables *****************************************************/
	/* See also the data table styling section, which this effectively subclasses */

	table.index {
		font-size: small;
		border-collapse: collapse;
		border-spacing: 0;
		text-align: left;
		margin: 1em 0;
	}

	table.index td,
	table.index th {
		padding: 0.4em;
	}

	table.index tr:hover td:not([rowspan]),
	table.index tr:hover th:not([rowspan]) {
		background: #f7f8f9;
	}

	/* The link in the first column in the property table (formerly a TD) */
	table.index th:first-child a {
		font-weight: bold;
	}

/******************************************************************************/
/*                                    Print                                   */
/******************************************************************************/

	@media print {
		/* Pages have their own margins. */
		html {
			margin: 0;
		}
		/* Serif for print. */
		body {
			font-family: serif;
		}
	}
	@page {
		margin: 1.5cm 1.1cm;
	}

/******************************************************************************/
/*                                    Legacy                                  */
/******************************************************************************/

	/* This rule is inherited from past style sheets. No idea what it's for. */
	.hide { display: none }



/******************************************************************************/
/*                             Overflow Control                               */
/******************************************************************************/

	.figure .caption, .sidefigure .caption, figcaption {
		/* in case figure is overlarge, limit caption to 50em */
		max-width: 50rem;
		margin-left: auto;
		margin-right: auto;
	}
	.overlarge {
		/* Magic to create good table positioning:
		   "content column" is 50ems wide at max; less on smaller screens.
		   Extra space (after ToC + content) is empty on the right.

		   1. When table < content column, centers table in column.
		   2. When content < table < available, left-aligns.
		   3. When table > available, fills available + scroll bar.
		*/ 
		display: grid;
		grid-template-columns: minmax(0, 50em);
	}
	.overlarge > table {
		/* limit preferred width of table */
		max-width: 50em;
		margin-left: auto;
		margin-right: auto;
	}

	@media (min-width: 55em) {
		.overlarge {
			margin-right: calc(13px + 26.5rem - 50vw);
			max-width: none;
		}
	}
	@media screen and (min-width: 78em) {
		body:not(.toc-inline) .overlarge {
			/* 30.5em body padding 50em content area */
			margin-right: calc(40em - 50vw) !important;
		}
	}
	@media screen and (min-width: 90em) {
		body:not(.toc-inline) .overlarge {
			/* 4em html margin 30.5em body padding 50em content area */
			margin-right: calc(84.5em - 100vw) !important;
		}
	}

	@media not print {
		.overlarge {
			overflow-x: auto;
			/* See Lea Verou's explanation background-attachment:
			 * http://lea.verou.me/2012/04/background-attachment-local/
			 *
			background: top left  / 4em 100% linear-gradient(to right,  #ffffff, rgba(255, 255, 255, 0)) local,
			            top right / 4em 100% linear-gradient(to left, #ffffff, rgba(255, 255, 255, 0)) local,
			            top left  / 1em 100% linear-gradient(to right,  #c3c3c5, rgba(195, 195, 197, 0)) scroll,
			            top right / 1em 100% linear-gradient(to left, #c3c3c5, rgba(195, 195, 197, 0)) scroll,
			            white;
			background-repeat: no-repeat;
			*/
		}
	}
</style>
<style type="text/css">
    table, th, td {
      border: 1px solid black;
      border-collapse: collapse;
      vertical-align: top;
    }
    th, td {
      border-left: none;
      border-right: none;
      padding: 0px 10px;
    }
    th {
      text-align: center;
    }

    del { background: #fcc; color: #000; text-decoration: line-through; }
    ins { background: #cfc; color: #000; }
    blockquote .highlight:not(.idl) { background: initial; margin: initial; padding: 0.5em }
    blockquote ul { background: inherit; }
    blockquote code.highlight:not(.idl) { padding: initial; }
    blockquote c-[a] { color: inherit; } /* Keyword.Declaration */
    blockquote c-[b] { color: inherit; } /* Keyword.Type */
    blockquote c-[c] { color: inherit; } /* Comment */
    blockquote c-[d] { color: inherit; } /* Comment.Multiline */
    blockquote c-[e] { color: inherit; } /* Name.Attribute */
    blockquote c-[f] { color: inherit; } /* Name.Tag */
    blockquote c-[g] { color: inherit; } /* Name.Variable */
    blockquote c-[k] { color: inherit; } /* Keyword */
    blockquote c-[l] { color: inherit; } /* Literal */
    blockquote c-[m] { color: inherit; } /* Literal.Number */
    blockquote c-[n] { color: inherit; } /* Name */
    blockquote c-[o] { color: inherit; } /* Operator */
    blockquote c-[p] { color: inherit; } /* Punctuation */
    blockquote c-[s] { color: inherit; } /* Literal.String */
    blockquote c-[t] { color: inherit; } /* Literal.String.Single */
    blockquote c-[u] { color: inherit; } /* Literal.String.Double */
    blockquote c-[cp] { color: inherit; } /* Comment.Preproc */
    blockquote c-[c1] { color: inherit; } /* Comment.Single */
    blockquote c-[cs] { color: inherit; } /* Comment.Special */
    blockquote c-[kc] { color: inherit; } /* Keyword.Constant */
    blockquote c-[kn] { color: inherit; } /* Keyword.Namespace */
    blockquote c-[kp] { color: inherit; } /* Keyword.Pseudo */
    blockquote c-[kr] { color: inherit; } /* Keyword.Reserved */
    blockquote c-[ld] { color: inherit; } /* Literal.Date */
    blockquote c-[nc] { color: inherit; } /* Name.Class */
    blockquote c-[no] { color: inherit; } /* Name.Constant */
    blockquote c-[nd] { color: inherit; } /* Name.Decorator */
    blockquote c-[ni] { color: inherit; } /* Name.Entity */
    blockquote c-[ne] { color: inherit; } /* Name.Exception */
    blockquote c-[nf] { color: inherit; } /* Name.Function */
    blockquote c-[nl] { color: inherit; } /* Name.Label */
    blockquote c-[nn] { color: inherit; } /* Name.Namespace */
    blockquote c-[py] { color: inherit; } /* Name.Property */
    blockquote c-[ow] { color: inherit; } /* Operator.Word */
    blockquote c-[mb] { color: inherit; } /* Literal.Number.Bin */
    blockquote c-[mf] { color: inherit; } /* Literal.Number.Float */
    blockquote c-[mh] { color: inherit; } /* Literal.Number.Hex */
    blockquote c-[mi] { color: inherit; } /* Literal.Number.Integer */
    blockquote c-[mo] { color: inherit; } /* Literal.Number.Oct */
    blockquote c-[sb] { color: inherit; } /* Literal.String.Backtick */
    blockquote c-[sc] { color: inherit; } /* Literal.String.Char */
    blockquote c-[sd] { color: inherit; } /* Literal.String.Doc */
    blockquote c-[se] { color: inherit; } /* Literal.String.Escape */
    blockquote c-[sh] { color: inherit; } /* Literal.String.Heredoc */
    blockquote c-[si] { color: inherit; } /* Literal.String.Interpol */
    blockquote c-[sx] { color: inherit; } /* Literal.String.Other */
    blockquote c-[sr] { color: inherit; } /* Literal.String.Regex */
    blockquote c-[ss] { color: inherit; } /* Literal.String.Symbol */
    blockquote c-[vc] { color: inherit; } /* Name.Variable.Class */
    blockquote c-[vg] { color: inherit; } /* Name.Variable.Global */
    blockquote c-[vi] { color: inherit; } /* Name.Variable.Instance */
    blockquote c-[il] { color: inherit; } /* Literal.Number.Integer.Long */
  </style>
  <link href="http://wg21.link/P0907r2" rel="canonical">
  <link href="https://isocpp.org/favicon.ico" rel="icon">
<style>/* style-md-lists */

/* This is a weird hack for me not yet following the commonmark spec
   regarding paragraph and lists. */
[data-md] > :first-child {
    margin-top: 0;
}
[data-md] > :last-child {
    margin-bottom: 0;
}</style>
<style>/* style-hidedel */

            #hidedel:checked ~ del, #hidedel:checked ~ * del { display:none; }
            #hidedel ~ #hidedel-label::before, #hidedel ~ * #hidedel-label::before { content: "☐ "; }
            #hidedel:checked ~ #hidedel-label::before, #hidedel:checked ~ * #hidedel-label::before { content: "☑ "; }
        </style>
<style>/* style-selflinks */

.heading, .issue, .note, .example, li, dt {
    position: relative;
}
a.self-link {
    position: absolute;
    top: 0;
    left: calc(-1 * (3.5rem - 26px));
    width: calc(3.5rem - 26px);
    height: 2em;
    text-align: center;
    border: none;
    transition: opacity .2s;
    opacity: .5;
}
a.self-link:hover {
    opacity: 1;
}
.heading > a.self-link {
    font-size: 83%;
}
li > a.self-link {
    left: calc(-1 * (3.5rem - 26px) - 2em);
}
dfn > a.self-link {
    top: auto;
    left: auto;
    opacity: 0;
    width: 1.5em;
    height: 1.5em;
    background: gray;
    color: white;
    font-style: normal;
    transition: opacity .2s, background-color .2s, color .2s;
}
dfn:hover > a.self-link {
    opacity: 1;
}
dfn > a.self-link:hover {
    color: black;
}

a.self-link::before            { content: "¶"; }
.heading > a.self-link::before { content: "§"; }
dfn > a.self-link::before      { content: "#"; }</style>
<style>/* style-counters */

body {
    counter-reset: example figure issue;
}
.issue {
    counter-increment: issue;
}
.issue:not(.no-marker)::before {
    content: "Issue " counter(issue);
}

.example {
    counter-increment: example;
}
.example:not(.no-marker)::before {
    content: "Example " counter(example);
}
.invalid.example:not(.no-marker)::before,
.illegal.example:not(.no-marker)::before {
    content: "Invalid Example" counter(example);
}

figcaption {
    counter-increment: figure;
}
figcaption:not(.no-marker)::before {
    content: "Figure " counter(figure) " ";
}</style>
<style>/* style-autolinks */

.css.css, .property.property, .descriptor.descriptor {
    color: #005a9c;
    font-size: inherit;
    font-family: inherit;
}
.css::before, .property::before, .descriptor::before {
    content: "‘";
}
.css::after, .property::after, .descriptor::after {
    content: "’";
}
.property, .descriptor {
    /* Don't wrap property and descriptor names */
    white-space: nowrap;
}
.type { /* CSS value <type> */
    font-style: italic;
}
pre .property::before, pre .property::after {
    content: "";
}
[data-link-type="property"]::before,
[data-link-type="propdesc"]::before,
[data-link-type="descriptor"]::before,
[data-link-type="value"]::before,
[data-link-type="function"]::before,
[data-link-type="at-rule"]::before,
[data-link-type="selector"]::before,
[data-link-type="maybe"]::before {
    content: "‘";
}
[data-link-type="property"]::after,
[data-link-type="propdesc"]::after,
[data-link-type="descriptor"]::after,
[data-link-type="value"]::after,
[data-link-type="function"]::after,
[data-link-type="at-rule"]::after,
[data-link-type="selector"]::after,
[data-link-type="maybe"]::after {
    content: "’";
}

[data-link-type].production::before,
[data-link-type].production::after,
.prod [data-link-type]::before,
.prod [data-link-type]::after {
    content: "";
}

[data-link-type=element],
[data-link-type=element-attr] {
    font-family: Menlo, Consolas, "DejaVu Sans Mono", monospace;
    font-size: .9em;
}
[data-link-type=element]::before { content: "<" }
[data-link-type=element]::after  { content: ">" }

[data-link-type=biblio] {
    white-space: pre;
}</style>
<style>/* style-syntax-highlighting */

.highlight:not(.idl) { background: hsl(24, 20%, 95%); }
code.highlight { padding: .1em; border-radius: .3em; }
pre.highlight, pre > code.highlight { display: block; padding: 1em; margin: .5em 0; overflow: auto; border-radius: 0; }
c-[a] { color: #990055 } /* Keyword.Declaration */
c-[b] { color: #990055 } /* Keyword.Type */
c-[c] { color: #708090 } /* Comment */
c-[d] { color: #708090 } /* Comment.Multiline */
c-[e] { color: #0077aa } /* Name.Attribute */
c-[f] { color: #669900 } /* Name.Tag */
c-[g] { color: #222222 } /* Name.Variable */
c-[k] { color: #990055 } /* Keyword */
c-[l] { color: #000000 } /* Literal */
c-[m] { color: #000000 } /* Literal.Number */
c-[n] { color: #0077aa } /* Name */
c-[o] { color: #999999 } /* Operator */
c-[p] { color: #999999 } /* Punctuation */
c-[s] { color: #a67f59 } /* Literal.String */
c-[t] { color: #a67f59 } /* Literal.String.Single */
c-[u] { color: #a67f59 } /* Literal.String.Double */
c-[cp] { color: #708090 } /* Comment.Preproc */
c-[c1] { color: #708090 } /* Comment.Single */
c-[cs] { color: #708090 } /* Comment.Special */
c-[kc] { color: #990055 } /* Keyword.Constant */
c-[kn] { color: #990055 } /* Keyword.Namespace */
c-[kp] { color: #990055 } /* Keyword.Pseudo */
c-[kr] { color: #990055 } /* Keyword.Reserved */
c-[ld] { color: #000000 } /* Literal.Date */
c-[nc] { color: #0077aa } /* Name.Class */
c-[no] { color: #0077aa } /* Name.Constant */
c-[nd] { color: #0077aa } /* Name.Decorator */
c-[ni] { color: #0077aa } /* Name.Entity */
c-[ne] { color: #0077aa } /* Name.Exception */
c-[nf] { color: #0077aa } /* Name.Function */
c-[nl] { color: #0077aa } /* Name.Label */
c-[nn] { color: #0077aa } /* Name.Namespace */
c-[py] { color: #0077aa } /* Name.Property */
c-[ow] { color: #999999 } /* Operator.Word */
c-[mb] { color: #000000 } /* Literal.Number.Bin */
c-[mf] { color: #000000 } /* Literal.Number.Float */
c-[mh] { color: #000000 } /* Literal.Number.Hex */
c-[mi] { color: #000000 } /* Literal.Number.Integer */
c-[mo] { color: #000000 } /* Literal.Number.Oct */
c-[sb] { color: #a67f59 } /* Literal.String.Backtick */
c-[sc] { color: #a67f59 } /* Literal.String.Char */
c-[sd] { color: #a67f59 } /* Literal.String.Doc */
c-[se] { color: #a67f59 } /* Literal.String.Escape */
c-[sh] { color: #a67f59 } /* Literal.String.Heredoc */
c-[si] { color: #a67f59 } /* Literal.String.Interpol */
c-[sx] { color: #a67f59 } /* Literal.String.Other */
c-[sr] { color: #a67f59 } /* Literal.String.Regex */
c-[ss] { color: #a67f59 } /* Literal.String.Symbol */
c-[vc] { color: #0077aa } /* Name.Variable.Class */
c-[vg] { color: #0077aa } /* Name.Variable.Global */
c-[vi] { color: #0077aa } /* Name.Variable.Instance */
c-[il] { color: #000000 } /* Literal.Number.Integer.Long */
</style>
 <body class="h-entry">
  <input id="hidedel" style="display:none" type="checkbox">
  <div class="head">
   <p data-fill-with="logo"></p>
   <h1 class="p-name no-ref" id="title">P0907R2<br>Signed Integers are Two’s Complement</h1>
   <h2 class="no-num no-toc no-ref heading settled" id="subtitle"><span class="content">Published Proposal, <time class="dt-updated" datetime="1970-01-01">1970-01-01</time></span></h2>
   <div data-fill-with="spec-metadata">
    <dl>
     <dt>This version:
     <dd><a class="u-url" href="http://wg21.link/P0907r2">http://wg21.link/P0907r2</a>
     <dt>Author:
     <dd>
      <dd class="editor p-author h-card vcard"><a class="p-name fn u-email email" href="mailto:jfbastien@apple.com">JF Bastien</a> (<span class="p-org org">Apple</span>)
     <dt>Audience:
     <dd>EWG
     <dt>Toggle Diffs:
     <dd>
      <label for="hidedel" id="hidedel-label">Hide deleted text</label>
     <dt>Project:
     <dd>ISO/IEC JTC1/SC22/WG21 14882: Programming Language — C++
     <dt>Source:
     <dd><a href="https://github.com/jfbastien/papers/blob/master/source/P0907r2.bs">github.com/jfbastien/papers/blob/master/source/P0907r2.bs</a>
    </dl>
   </div>
   <div data-fill-with="warning"></div>
   <hr title="Separator for header">
  </div>
  <div class="p-summary" data-fill-with="abstract">
   <h2 class="no-num no-toc no-ref heading settled" id="abstract"><span class="content">Abstract</span></h2>
   <p>There is One True Representation for signed integers, and that representation is two’s complement.</p>
  </div>
  <nav data-fill-with="table-of-contents" id="toc">
   <h2 class="no-num no-toc no-ref" id="contents">Table of Contents</h2>
   <ol class="toc" role="directory">
    <li><a href="#intro"><span class="secno">1</span> <span class="content">Introduction</span></a>
    <li>
     <a href="#edit"><span class="secno">2</span> <span class="content">Edit History</span></a>
     <ol class="toc">
      <li><a href="#r1r2"><span class="secno">2.1</span> <span class="content">r1 → r2</span></a>
      <li>
       <a href="#r0r1"><span class="secno">2.2</span> <span class="content">r0 → r1</span></a>
       <ol class="toc">
        <li><a href="#sg6-sg12"><span class="secno">2.2.1</span> <span class="content">SG6 / SG12</span></a>
        <li><a href="#ewg"><span class="secno">2.2.2</span> <span class="content">EWG</span></a>
       </ol>
     </ol>
    <li><a href="#word"><span class="secno">3</span> <span class="content">Proposed Wording</span></a>
    <li><a href="#scope"><span class="secno">4</span> <span class="content">Out of Scope</span></a>
    <li><a href="#c-sign"><span class="secno">5</span> <span class="content">C Signed Integer Wording</span></a>
    <li><a href="#survey"><span class="secno">6</span> <span class="content">Survey of Signed Integer Representations</span></a>
    <li><a href="#WG14"><span class="secno">7</span> <span class="content">WG14 Feedback from the Brno Meeting</span></a>
    <li>
     <a href="#references"><span class="secno"></span> <span class="content">References</span></a>
     <ol class="toc">
      <li><a href="#informative"><span class="secno"></span> <span class="content">Informative References</span></a>
     </ol>
    <li><a href="#issues-index"><span class="secno"></span> <span class="content">Issues Index</span></a>
   </ol>
  </nav>
  <main>
   <h2 class="heading settled" data-level="1" id="intro"><span class="secno">1. </span><span class="content">Introduction</span><a class="self-link" href="#intro"></a></h2>
   <p><a data-link-type="biblio" href="#biblio-c11">[C11]</a> Integer types allows three representations for signed integral types:</p>
   <ul>
    <li data-md>
     <p>Signed magnitude</p>
    <li data-md>
     <p>Ones' complement</p>
    <li data-md>
     <p>Two’s complement</p>
   </ul>
   <p>See <a href="#c-sign">§ 5 C Signed Integer Wording</a> for full wording.</p>
   <p>C++ goes further than C and only requires that "the representations of integral
types shall define values by use of a pure binary numeration system". To the
author’s knowledge no modern machine uses both C++ and a signed integer
representation other than two’s complement (see <a href="#survey">§ 6 Survey of Signed Integer Representations</a>). None of <a data-link-type="biblio" href="#biblio-msvc">[MSVC]</a>, <a data-link-type="biblio" href="#biblio-gcc">[GCC]</a>, and <a data-link-type="biblio" href="#biblio-llvm">[LLVM]</a> support other representations. This means that the C++
that is taught is effectively two’s complement, and the C++ that is written is
two’s complement. It is extremely unlikely that there exist any significant
codebase developed for two’s complement machines that would actually work when
run on a non-two’s complement machine.</p>
   <p>C and C++ as specified, however, are not two’s complement. Signed integers
currently allow the existence of an extraordinary value which traps, extra
padding bits, integral negative zero, and introduce undefined behavior and
implementation-defined behavior for the sake of this <em>extremely</em> abstract
machine.</p>
   <p>Let’s stop pretending that the abstract machine should represent integers as
signed magnitude or ones' complement. These theoretical implementations are a
different programming language, not our real-world C++. Developers who require
signed magnitude or ones' complement integers would be better served by a
pure-library solution, and so would the rest of us.</p>
   <p>This paper proposes the following:</p>
   <ul>
    <li data-md>
     <p><em>Status-quo</em> Signed integer arithmetic remains non-commutative in general
(though some implementations may guarantee that it is).</p>
    <li data-md>
     <p><em>Change</em> <code class="highlight"><c- b>bool</c-></code> is represented as <code class="highlight"><c- mi>0</c-></code> for <code class="highlight">false</code> and <code class="highlight"><c- mi>1</c-></code> for <code class="highlight">true</code>. All
other representations are undefined.</p>
    <li data-md>
     <p><em>Change</em> <code class="highlight"><c- b>bool</c-></code> only has value bits, no padding bits.</p>
    <li data-md>
     <p><em>Change</em> Signed integers are two’s complement.</p>
    <li data-md>
     <p><em>Change</em> If there are <em>M</em> value bits in the signed type and <em>N</em> in the
unsigned type, then <em>M = N-1</em> (whereas C says <em>M ≤ N</em>).</p>
    <li data-md>
     <p><em>Status-quo</em> If a signed operation would naturally produce a value that is
not within the range of the result type, the behavior is undefined. The
author had hoped to make this well-defined as wrapping (the operations
produce the same value bits as for the corresponding unsigned type), but
WG21 had strong resistance against this.</p>
    <li data-md>
     <p><em>Change</em> None of the integral types have extraordinary values.</p>
    <li data-md>
     <p><em>Change</em> C11 note 53 has wording aroung trap representations within padding
bits, e.g. for parity bits. C++ has no such wording.</p>
    <li data-md>
     <p><em>Change</em> Conversion from signed to unsigned is always well-defined: the
result is the unique value of the destination type that is congruent to the
source integer modulo 2<sup>N</sup>.</p>
    <li data-md>
     <p><em>Change</em> Conversion from enumeration type to integral is the same as that of
converting from the enumeration’s underlying type and then to the
destination type, even if the original value cannot be represented by the
specified type.</p>
    <li data-md>
     <p><em>Status-quo</em> Conversion from integral type to enumeration is unchanged: if
the original value is not within the range of the enumeration values the
behavior is undefined.</p>
    <li data-md>
     <p><em>Change</em> Left-shift on signed integer types produces the same results as
left-shift on the corresponding unsigned integer type.</p>
    <li data-md>
     <p><em>Change</em> Right-shift is an arithmetic right shift which performs
sign-extension.</p>
    <li data-md>
     <p><em>Status-quo</em> shift by larger-than or equal-to bit-width remains undefined.</p>
    <li data-md>
     <p><em>Status-quo</em> <code class="highlight"><c- k>constexpr</c-></code> evaluation of signed integer arithmetic with
undefined result is not a <em>core constant expression</em>.</p>
    <li data-md>
     <p><em>Change</em> the range of enumerations without a fixed underlying type is
simplified because of two’s complement.</p>
    <li data-md>
     <p><em>Status-quo</em> <code class="highlight"><c- n>is_modulo</c-></code> type trait remains <code class="highlight">false</code> for signed integer types
unless an implementation chooses to defined overflow as wrap.</p>
    <li data-md>
     <p><code class="highlight"><c- n>has_unique_object_representations</c-><c- o>&lt;</c-><c- n>T</c-><c- o>></c-></code> is <code class="highlight">true</code> for <code class="highlight"><c- b>bool</c-></code> and signed
integer types, in addition to unsigned integer types and others before.</p>
    <li data-md>
     <p><em>Status-quo</em> atomic operations on signed integer types continues not to have
undefined behavior, and is still specified to wrap as two’s complement (the
definition is clarified to act as-if casting to unsigned and back).</p>
    <li data-md>
     <p><em>Change</em> address <a data-link-type="biblio" href="#biblio-lwg3047">[LWG3047]</a> to remove undefined behavior in pre-increment
atomic operations.</p>
   </ul>
   <p>This proposal leaves C unchanged, it merely restricts further the subset of C
which applies to C++. Aaron Ballman volunteered to present this paper and the
corresponding <a data-link-type="biblio" href="#biblio-n2218">[N2218]</a> to WG14, in the hope that C will approve compatible
changes. The WG14 feedback is summarized in <a href="#WG14">§ 7 WG14 Feedback from the Brno Meeting</a>.</p>
   <p>A final argument to move to two’s complement is that few people spell "ones'
complement" correctly according to Knuth <a data-link-type="biblio" href="#biblio-taocp">[TAoCP]</a>. Reducing the nerd-snipe
potential inherent in C++ is a Good Thing™.</p>
   <blockquote>
    <p>Detail-oriented readers and copy editors should notice the position of the
  apostrophe in terms like “two’s complement” and “ones’ complement”: A two’s
  complement number is complemented with respect to a single power of 2, while a
  ones’ complement number is complemented with respect to a long sequence of
  1s. Indeed, there is also a “twos’ complement notation,” which has radix 3 and
  complementation with respect to (2 . . . 22)<sub>3</sub>.</p>
   </blockquote>
   <h2 class="heading settled" data-level="2" id="edit"><span class="secno">2. </span><span class="content">Edit History</span><a class="self-link" href="#edit"></a></h2>
   <h3 class="heading settled" data-level="2.1" id="r1r2"><span class="secno">2.1. </span><span class="content">r1 → r2</span><a class="self-link" href="#r1r2"></a></h3>
   <p>Update with feedback from WG14, available in <a href="#WG14">§ 7 WG14 Feedback from the Brno Meeting</a>.</p>
   <h3 class="heading settled" data-level="2.2" id="r0r1"><span class="secno">2.2. </span><span class="content">r0 → r1</span><a class="self-link" href="#r0r1"></a></h3>
   <p>This paper was presented in Jacksonville to:</p>
   <ul>
    <li data-md>
     <p>A joint SG6 numerics and SG12 undefined behavior session</p>
    <li data-md>
     <p>The Evolution Working Group</p>
   </ul>
   <p>The following polls were taken, and corresponding modifications made to the
paper. The main change between <a data-link-type="biblio" href="#biblio-p0907r0">[P0907r0]</a> and the subsequent revision is to
maintain undefined behavior when signed integer overflow occurs, instead of
defining wrapping behavior. This direction was motivated by:</p>
   <ul>
    <li data-md>
     <p>Performance concerns, whereby defining the behavior prevents optimizers from
assuming that overflow never occurs;</p>
    <li data-md>
     <p>Implementation leeway for tools such as sanitizers;</p>
    <li data-md>
     <p>Data from Google suggesting that over 90% of all overflow is a bug, and
defining wrapping behavior would not have solved the bug.</p>
   </ul>
   <p>It is expected that this paper have little to no effect on code generation from
current compilers. Known codegen changes should have no performance implication,
for example:</p>
   <ul>
    <li data-md>
     <p>Older x86 vector instructions don’t support arithmetic right shift, and
therefore must remain scalar instead of vectorizing to non-arithmetic right
shift.</p>
    <li data-md>
     <p>An implementation which implements left shift using a rotate now need to
also mask.</p>
   </ul>
   <h4 class="heading settled" data-level="2.2.1" id="sg6-sg12"><span class="secno">2.2.1. </span><span class="content">SG6 / SG12</span><a class="self-link" href="#sg6-sg12"></a></h4>
   <table class="def">
    <tbody>
     <tr>
      <th style="width: 70%;">
      <th><strong>SF</strong>
      <th><strong>F</strong>
      <th><strong>N</strong>
      <th><strong>A</strong>
      <th><strong>SA</strong>
     <tr>
      <th><small>Change anything with respect to signed integers.</small>
      <th>2
      <th>10
      <th>5
      <th>1
      <th>0
     <tr>
      <th><small>Moving any change from this paper to IS’20 is blocked on synchronizing with WG14.</small>
      <th>4
      <th>9
      <th>4
      <th>0
      <th>1
     <tr>
      <th><small>Change the default unsigned integral types' behavior.</small>
      <th>0
      <th>0
      <th>1
      <th>8
      <th>9
     <tr>
      <th><small>Changes we make constrain <em>extended integral types</em>.</small>
      <th>10
      <th>4
      <th>2
      <th>0
      <th>1
     <tr>
      <th><small>Allow <em>extraordinary value</em> for signed integral types.</small>
      <th>2
      <th>2
      <th>9
      <th>2
      <th>3
   </table>
   <p>We decided to independently conside what the "privileged" syntax' behavior
should be when going out of range for:</p>
   <ul>
    <li data-md>
     <p>cast of enums</p>
    <li data-md>
     <p>cast from <code class="highlight"><c- b>unsigned</c-></code> to <code class="highlight"><c- b>signed</c-></code></p>
    <li data-md>
     <p><code class="highlight"><c- n>INT_MIN</c-> <c- o>/</c-> <c- o>-</c-><c- mi>1</c-></code></p>
    <li data-md>
     <p>addition / subtraction / multiplication and <code class="highlight"><c- o>-</c-><c- n>INT_MIN</c-></code> overflow</p>
   </ul>
   <p><strong>Multiple answer poll</strong> would you be OK with these being the standards-mandated
behavior for the "privileged" syntax behavior of signed integral types when
going out of range:</p>
   <ul>
    <li data-md>
     <p>16—undefined behavior</p>
    <li data-md>
     <p>0—saturation</p>
    <li data-md>
     <p>0—trap (exception)</p>
    <li data-md>
     <p>1—trap (abort)</p>
    <li data-md>
     <p>1—generate extraordinary value</p>
    <li data-md>
     <p>11—wrap</p>
    <li data-md>
     <p>5—Rust-style wrap or trap, maybe contract violation?</p>
    <li data-md>
     <p>9—intermediate values are mathematical integers (e.g. <code class="highlight"><c- p>(</c-><c- b>int</c-><c- p>)</c-><c- n>a</c-><c- o>+</c-><c- p>(</c-><c- b>int</c-><c- p>)</c-><c- n>b</c-> <c- o>></c-> <c- n>INT_MAX</c-></code> would be OK)</p>
   </ul>
   <table class="def">
    <tbody>
     <tr>
      <th style="width: 70%;">
      <th><strong>SF</strong>
      <th><strong>F</strong>
      <th><strong>N</strong>
      <th><strong>A</strong>
      <th><strong>SA</strong>
     <tr>
      <th><small>Cast to enums outside of the enum’s representable range should be defined instead of undefined behavior.</small>
      <th>0
      <th>1
      <th>1
      <th>5
      <th>8
     <tr>
      <th><small>Cast from <code class="highlight"><c- b>unsigned</c-></code> to <code class="highlight"><c- b>signed</c-></code> which are out of range is currently implementation defined. It should instead be wrap.</small>
      <th>6
      <th>6
      <th>3
      <th>0
      <th>1
     <tr>
      <th><small>We want two’s complement representation for signed types, regardless of what WG14 decides.</small>
      <th>7
      <th>4
      <th>2
      <th>0
      <th>3
     <tr>
      <th><small><code class="highlight"><c- n>INT_MIN</c-> <c- o>/</c-> <c- o>-</c-><c- mi>1</c-></code> should be defined.</small>
      <th>0
      <th>0
      <th>4
      <th>3
      <th>9
   </table>
   <p><strong>Multiple answer poll</strong> addition / subtraction / multiplication and <code class="highlight"><c- o>-</c-><c- n>INT_MIN</c-></code> overflow is currently undefined behavior, it should instead be:</p>
   <ul>
    <li data-md>
     <p>4—wrap</p>
    <li data-md>
     <p>6—wrap or trap</p>
    <li data-md>
     <p>5—intermediate values are mathematical integers</p>
    <li data-md>
     <p>14—status quo (remain undefined behavior)</p>
   </ul>
   <p><strong>Multiple answer poll</strong> to opt-in to the other behaviors (both for <code class="highlight"><c- b>signed</c-></code> and <code class="highlight"><c- b>unsigned</c-></code>) we can create library or language changes. What should we explore
separately from this paper?</p>
   <ul>
    <li data-md>
     <p>12—undefined behavior</p>
    <li data-md>
     <p>9—saturation</p>
    <li data-md>
     <p>8—trap (exception)</p>
    <li data-md>
     <p>6—trap (abort)</p>
    <li data-md>
     <p>3—generate extraordinary value</p>
    <li data-md>
     <p>16—wrap</p>
    <li data-md>
     <p>10—Rust-style wrap or trap, maybe contract violation?</p>
    <li data-md>
     <p>9—intermediate values are mathematical integers (e.g. <code class="highlight"><c- p>(</c-><c- b>int</c-><c- p>)</c-><c- n>a</c-><c- o>+</c-><c- p>(</c-><c- b>int</c-><c- p>)</c-><c- n>b</c-> <c- o>></c-> <c- n>INT_MAX</c-></code> would be OK)</p>
    <li data-md>
     <p>13—bigint</p>
    <li data-md>
     <p>14—operations with a bool set when overflow has occurred</p>
   </ul>
   <table class="def">
    <tbody>
     <tr>
      <th style="width: 70%;">
      <th><strong>SF</strong>
      <th><strong>F</strong>
      <th><strong>N</strong>
      <th><strong>A</strong>
      <th><strong>SA</strong>
     <tr>
      <th><small>Shifting out of range <code class="highlight"><c- mi>1</c-> <c- o>&lt;&lt;</c-> <c- mi>31</c-></code> as currently defined (if shift has
defined value when interpreted as unsigned, you get that value as signed, you
can shift into but not past the sign, shifting past sign bit is undefined
behavior). <code class="highlight"><c- mi>1</c-> <c- o>&lt;&lt;</c-> <c- mi>31</c-></code> was defined and still is (as of Howard’s paper), <code class="highlight"><c- mi>2</c-> <c- o>&lt;&lt;</c-> <c- mi>31</c-></code> was undefined behavior and still is. WG14 is currently considering whether to
adopt Howard’s paper which made this. Should we take it back to undefined to do <code class="highlight"><c- mi>1</c-> <c- o>&lt;&lt;</c-> <c- mi>31</c-></code>?</small>
      <th>2
      <th>7
      <th>5
      <th>1
      <th>1
     <tr>
      <th><small>Left shift should be the same for <code class="highlight"><c- b>signed</c-></code> and <code class="highlight"><c- b>unsigned</c-></code> (<em>overrides previous poll</em>).</small>
      <th>6
      <th>5
      <th>5
      <th>0
      <th>1
     <tr>
      <th><small>Right shift on a signed integral type should be an arithmetic shift (which sign-extends).</small>
      <th>9
      <th>4
      <th>3
      <th>1
      <th>0
     <tr>
      <th><small>In C <code class="highlight"><c- n>intN_t</c-></code> is optional: “These types are optional. However, if an
implementation provides integer types with widths of 8, 16, 32, or 64 bits, no
padding bits, and (for the signed types) that have a two’s complement
representation, it shall define the corresponding typedef names.”  Change it to
make <code class="highlight"><c- b>int8_t</c-></code>, <code class="highlight"><c- b>int16_t</c-></code>, <code class="highlight"><c- b>int32_t</c-></code>, and <code class="highlight"><c- b>int64_t</c-></code> not optional. </small>
      <th>1
      <th>0
      <th>2
      <th>3
      <th>12
   </table>
   <h4 class="heading settled" data-level="2.2.2" id="ewg"><span class="secno">2.2.2. </span><span class="content">EWG</span><a class="self-link" href="#ewg"></a></h4>
   <p>The Evolution Working Group took the following polls:</p>
   <table class="def">
    <tbody>
     <tr>
      <th style="width: 70%;">
      <th><strong>SF</strong>
      <th><strong>F</strong>
      <th><strong>N</strong>
      <th><strong>A</strong>
      <th><strong>SA</strong>
     <tr>
      <th><small>Disallow extraordinary value (trapping / NaN) for signed integral types.</small>
      <th>16
      <th>12
      <th>7
      <th>1
      <th>2
     <tr>
      <th><small>Does EWG want to move signed integers to two’s complement, as presented
in the current paper (without extraordinary values)?</small>
      <th>11
      <th>17
      <th>7
      <th>2
      <th>1
     <tr>
      <th><small>Move to Core.</small>
      <th>7
      <th>8
      <th>12
      <th>8
      <th>4
   </table>
   <p>The resolution on disallowing extraordinary values overrides the lack of
consensus for change from SG6 / SG12.</p>
   <p>The decision to not forward to Core was mainly motivated on hearing back from
WG14. WG14 met in Brno, discussed <a data-link-type="biblio" href="#biblio-n2218">[N2218]</a>, and provided feedback detailed in <a href="#WG14">§ 7 WG14 Feedback from the Brno Meeting</a>. EWG will see the paper again in Rappersvil, and will likely forward
to Core at that point in time given the outcome of the next-to-last poll.</p>
   <h2 class="heading settled" data-level="3" id="word"><span class="secno">3. </span><span class="content">Proposed Wording</span><a class="self-link" href="#word"></a></h2>
   <p>Leave the note in Program execution [<strong>intro.execution</strong>] ❡8 as-is:</p>
   <blockquote>
    <p>[<em>Note:</em> Operators can be regrouped according to the usual mathematical
rules only where the operators really are associative or commutative.
For example, in the following fragment</p>
<pre class="highlight"><c- b>int</c-> <c- n>a</c-><c- p>,</c-> <c- n>b</c-><c- p>;</c->
<c- d>/* ... */</c->
<c- n>a</c-> <c- o>=</c-> <c- n>a</c-> <c- o>+</c-> <c- mi>32760</c-> <c- o>+</c-> <c- n>b</c-> <c- o>+</c-> <c- mi>5</c-><c- p>;</c->
</pre>
    <p>the expression statement behaves exactly the same as</p>
<pre class="highlight"><c- n>a</c-> <c- o>=</c-> <c- p>(((</c-><c- n>a</c-> <c- o>+</c-> <c- mi>32760</c-><c- p>)</c-> <c- o>+</c-> <c- n>b</c-><c- p>)</c-> <c- o>+</c-> <c- mi>5</c-><c- p>);</c->
</pre>
    <p>due to the associativity and precedence of these operators. Thus, the result of
the sum <code class="highlight"><c- p>(</c-><c- n>a</c-> <c- o>+</c-> <c- mi>32760</c-><c- p>)</c-></code> is next added to <code class="highlight"><c- n>b</c-></code>, and that result is then added to 5
which results in the value assigned to <code class="highlight"><c- n>a</c-></code>. On a machine in which overflows
produce an exception and in which the range of values representable by an <code class="highlight"><c- b>int</c-></code> is <code class="highlight"><c- p>[</c-><c- o>-</c-><c- mi>32768</c-><c- p>,</c-> <c- o>+</c-><c- mi>32767</c-><c- p>]</c-></code>, the implementation cannot rewrite this expression as</p>
<pre class="highlight"><c- n>a</c-> <c- o>=</c-> <c- p>((</c-><c- n>a</c-> <c- o>+</c-> <c- n>b</c-><c- p>)</c-> <c- o>+</c-> <c- mi>32765</c-><c- p>);</c->
</pre>
    <p>since if the values for <code class="highlight"><c- n>a</c-></code> and <code class="highlight"><c- n>b</c-></code> were, respectively, -32754 and -15, the sum <code class="highlight"><c- n>a</c-> <c- o>+</c-> <c- n>b</c-></code> would produce an exception while the original expression would not; nor
can the expression be rewritten either as</p>
<pre class="highlight"><c- n>a</c-> <c- o>=</c-> <c- p>((</c-><c- n>a</c-> <c- o>+</c-> <c- mi>32765</c-><c- p>)</c-> <c- o>+</c-> <c- n>b</c-><c- p>);</c->
</pre>
    <p>or</p>
<pre class="highlight"><c- n>a</c-> <c- o>=</c-> <c- p>(</c-><c- n>a</c-> <c- o>+</c-> <c- p>(</c-><c- n>b</c-> <c- o>+</c-> <c- mi>32765</c-><c- p>));</c->
</pre>
    <p>since the values for <code class="highlight"><c- n>a</c-></code> and <code class="highlight"><c- n>b</c-></code> might have been, respectively, 4 and -8 or -17
and 12. However on a machine in which overflows do not produce an exception and
in which the results of overflows are reversible, the above expression statement
can be rewritten by the implementation in any of the above ways because the same
result will occur. —<em>end note</em>]</p>
   </blockquote>
   <p>Modify Fundamental types [<strong>basic.fundamental</strong>] ❡4 onwards:</p>
   <blockquote>
    <p>Unsigned integers shall obey the laws of arithmetic modulo 2<sup>n</sup> where <em>n</em> is the number of bits in the value representation of that particular size of
integer.</p>
    <blockquote>
     <p>This implies that unsigned arithmetic does not overflow because a result that
  cannot be represented by the resulting unsigned integer type is reduced modulo
  the number that is one greater than the largest value that can be represented
  by the resulting unsigned integer type.</p>
    </blockquote>
    <p>Type <code class="highlight"><c- b>wchar_t</c-></code> is a distinct type whose values can represent distinct codes for
all members of the largest extended character set specified among the supported
locales. Type <code class="highlight"><c- b>wchar_t</c-></code> shall have the same size, signedness, and alignment
requirements as one of the other integral types, called its <em>underlying type</em>.
Types <code class="highlight"><c- b>char16_t</c-></code> and <code class="highlight"><c- b>char32_t</c-></code> denote distinct types with the same size,
signedness, and alignment as <code class="highlight"><c- b>uint_least16_t</c-></code> and <code class="highlight"><c- b>uint_least32_t</c-></code>,
respectively, in <code class="highlight"><c- o>&lt;</c-><c- n>cstdint</c-><c- o>></c-></code>, called the underlying types.</p>
    <p>
     Values of type <code class="highlight"><c- b>bool</c-></code> are either <code class="highlight">true</code> or <code class="highlight">false</code><sup>†</sup>. [<em>Note:</em> There are no <code class="highlight"><c- b>signed</c-></code>, <code class="highlight"><c- b>unsigned</c-></code>, <code class="highlight"><c- b>short</c-></code>, or <code class="highlight"><c- b>long</c-> <c- b>bool</c-></code> types or values. —<em>end note</em>]
Values of type <code class="highlight"><c- b>bool</c-></code> participate in integral promotions.
     <ins> Type <code class="highlight"><c- b>bool</c-></code>'s
object representation bits shall only contain value bits. The bits of the value
representation of type <code class="highlight"><c- b>bool</c-></code> shall all be zero for <code class="highlight">false</code>. For <code class="highlight">true</code>, all
bits shall be zero except for the bit corresponding to the least-significant bit
in the object representation of the unsigned type with the same size (or a
bit-field thereof) as <code class="highlight"><c- b>bool</c-></code>. The program has undefined behavior if any other
object representation is formed.</ins>
    </p>
    <blockquote>
     <p><sup>†</sup> Using a <code class="highlight"><c- b>bool</c-></code> value in ways described by this International
  Standard as “undefined”, such as by examining the value of an uninitialized
  automatic object, might cause it to behave as if it is neither <code class="highlight">true</code> nor <code class="highlight">false</code>.</p>
    </blockquote>
    <p class="issue" id="issue-540ad40f"><a class="self-link" href="#issue-540ad40f"></a> We need to define the storage for <code class="highlight"><c- b>bool</c-></code> since we define signed and
unsigned below, and that excludes <code class="highlight"><c- b>bool</c-></code>. The definition I propose is more
restrictive than what we had before because it only allows two values to be
represented, and doesn’t allow padding bits. This guarantees that <code class="highlight"><c- b>bool</c-></code> is
trivially-copyable, and gives it a unique object representation, which as far as
I know all compilers already guaranteed.</p>
    <p>
     Types <code class="highlight"><c- b>bool</c-></code>, <code class="highlight"><c- b>char</c-></code>, <code class="highlight"><c- b>char16_t</c-></code>, <code class="highlight"><c- b>char32_t</c-></code>, <code class="highlight"><c- b>wchar_t</c-></code>, and the signed and
unsigned integer types are collectively called <em>integral</em> types. A synonym for
integral type is <em>integer type</em>. 
     <del>The representations of integral types
shall define values by use of a pure binary numeration system<sup>‡</sup>. [<em>Example:</em> This document permits two’s complement, ones' complement and signed magnitude
representations for integral types. —<em>end example</em>]</del>
    </p>
    <p>
     <ins>For unsigned integer types, the bits of the object representation are
divided into two groups: value bits and padding bits. There need not be any
padding bits; <code class="highlight"><c- b>unsigned</c-> <c- b>char</c-></code> shall not have any padding bits. If there are <em>N</em> value bits, each bit shall represent a different power of 2 between 1 and
2<sup><em>N</em>−1</sup>, so that objects of that type shall be capable of representing
values from 0 to 2<sup><em>N</em></sup>−1 using a pure binary numeration
system<sup>‡</sup>; this shall be known as the value representation. The values
of any padding bits are unspecified.</ins>
    </p>
    <blockquote>
     <p><sup>‡</sup> A positional representation for integers that uses the binary
  digits 0 and 1, in which the values represented by successive bits are
  additive, begin with 1, and are multiplied by successive integral power of 2,
  except perhaps for the bit with the highest position. (Adapted from the <em>American National Dictionary for Information Processing Systems</em>.)</p>
    </blockquote>
    <p class="issue" id="issue-28d91b9b"><a class="self-link" href="#issue-28d91b9b"></a> An intermediate revision of this paper stated "Value bits are store
contiguously in memory" in an attempt to preserve different endiannesses, and
otherwise restricts implementations to "sane" layout. However, that change
wasn’t presented to EWG and received pushback on the SG6 reflector. Would this
be a desirable addition, should it be in a separate paper, or does it
overconstrain implementations?</p>
    <p>
     <ins>Signed integer types shall be repesented as two’s complement. The bits
of signed integer types' object representation are divided into three groups:
value bits, padding bits, and the sign bit. There need not be any padding bits; <code class="highlight"><c- b>signed</c-> <c- b>char</c-></code> shall not have any padding bits. There shall be exactly one sign
bit. Each bit that is a value bit shall have the same value as the same bit in
the object representation of the corresponding unsigned type (if there are <em>M</em> value bits in the signed type and <em>N</em> in the unsigned type, then <em>M = N-1</em>).
The value bit in the unsigned representation with value 2<sup>N-1</sup> corresponds to the sign bit in the signed representation, where it has value
-2<sup>N-1</sup>. [<em>Note:</em> Unless otherwise specified, if a signed operation
would naturally produce a value that is not within the range of the result
type, the behavior is undefined (see [<strong>expr.pre</strong>] 8). —<em>end note</em>]</ins>
    </p>
    <p class="issue" id="issue-5bda07bf"><a class="self-link" href="#issue-5bda07bf"></a> note <em>M = N-1</em>, whereas C says <em>M ≤ N</em>. I derive this from "For each of
the standard signed integer types, there exists a corresponding (but different)
standard unsigned integer type [...] <strong>each of which occupies the same
amount of storage</strong>".</p>
    <p>
     <ins>All combinations of value bits and sign bit are valid and result in a
specific distinct integer value. No other bits factor into an integer’s value.
[<em>Note:</em> Therefore, none of the integral types have extraordinary values as
defined in ISO C. —<em>end note</em>]</ins>
    </p>
    <p class="issue" id="issue-83f525f6"><a class="self-link" href="#issue-83f525f6"></a> In C11 implementation requirements call it the "extraordinary value" and
refer to 6.2.6.2 which calls it "is a trap representation or a normal
value". Furthermore, in note 53 there’s wording around extraordinary values
being held in padding bits (not just as a value stolen from the value
representation), and since C++ wording used to only talk about "binary
representation" it’d rather be very clear about the absence of extraordinary
values. It’s unclear whether SG6 / SG12 guidance explicitly wanted to disallow
padding bits from being special and trapping. I propose disallowing it.</p>
   </blockquote>
   <p>Modify Integral conversions [<strong>conv.integral</strong>] ❡1 onwards:</p>
   <blockquote>
    <p>A prvalue of an integer type can be converted to a prvalue of another integer
type. A prvalue of an unscoped enumeration type can be converted to a prvalue of
an integer type.</p>
    <del>If the destination type is unsigned, the resulting value is the least unsigned
integer congruent to the source integer (modulo 2<sup>n</sup> where <em>n</em> is the
number of bits used to represent the unsigned type). [<em>Note:</em> In a two’s
complement representation, this conversion is conceptual and there is no change
in the bit pattern (if there is no truncation). —<em>end note</em>]</del>
    <del>If the destination type is signed, the value is unchanged if it can be
represented in the destination type; otherwise, the value is
implementation-defined.</del>
    <p>
     <ins>For integral types other than <code class="highlight"><c- b>bool</c-></code>, the result is the unique value of
the destination type that is congruent to the source integer modulo
2<sup>N</sup>, where <em>N</em> is the number of value bits in the destination
type. [<em>Note:</em> This conversion is conceptual; there is no change in the bit
pattern other than that high-order bits may either be discarded or added. All
added high-order bits will have the same value.  —<em>end note</em>]</ins>
    </p>
   </blockquote>
   <p>Modify Static cast [<strong>expr.static.cast</strong>] ❡9 onwards:</p>
   <blockquote>
    <p>
     A value of a scoped enumeration type can be explicitly converted to an integral
type
     <del>. When that type is <em>cv</em> <code class="highlight"><c- b>bool</c-></code>, the resulting value is <code class="highlight">false</code> if the
original value is zero and <code class="highlight">true</code> for all other values. For the remaining
integral types, the value is unchanged if the original value can be represented
by the specified type. Otherwise, the resulting value is
unspecified.</del>
     <ins>; the result is the same as that of converting from the
enumeration’s underlying type and then to the destination type.</ins>
      A value of
a scoped enumeration type can also be explicitly converted to a floating-point
type; the result is the same as that of converting from the original value to
the floating-point type.
    </p>
    <p class="issue" id="issue-1a4cd6e3"><a class="self-link" href="#issue-1a4cd6e3"></a> the above change is for enumeration <em>to</em> integer, which SG6 did not
object to changing as suggested. It states the conversion in terms of the
updated [<strong>conv.integral</strong>] rules.</p>
    <p>A value of integral or enumeration type can be explicitly converted to a
complete enumeration type. If the enumeration type has a fixed underlying type,
the value is first converted to that type by integral conversion, if necessary,
and then to the enumeration type. If the enumeration type does not have a fixed
underlying type, the value is unchanged if the original value is within the
range of the enumeration values, and otherwise, the behavior is undefined. A
value of floating-point type can also be explicitly converted to an enumeration
type. The resulting value is the same as converting the original value to the
underlying type of the enumeration, and subsequently to the enumeration type.</p>
    <p class="issue" id="issue-0a0c2243"><a class="self-link" href="#issue-0a0c2243"></a> the above unmodified paragraph is for integer <em>to</em> enumeration which SG6
voted to leave undefined in poll "Cast to enums outside of the enum’s
representable range should be defined instead of undefined behavior".</p>
   </blockquote>
   <p>Modify Shift operators [<strong>expr.shift</strong>] ❡1 onwards:</p>
   <blockquote>
    <p>The operands shall be of integral or unscoped enumeration type and integral
promotions are performed. The type of the result is that of the promoted left
operand. The behavior is undefined if the right operand is negative, or greater
than or equal to the length in bits of the promoted left operand.</p>
    <p>
     The value of <code class="highlight"><c- n>E1</c-> <c- o>&lt;&lt;</c-> <c- n>E2</c-></code> is <code class="highlight"><c- n>E1</c-></code> left-shifted <code class="highlight"><c- n>E2</c-></code> bit positions; vacated bits
are zero-filled. 
     <del>If <code class="highlight"><c- n>E1</c-></code> has an unsigned type, the</del>
     <ins>The</ins>
      value of the result is E1×2<sup>E2</sup>, reduced modulo 
     <del>one more than the
maximum value representable in the result type. Otherwise, if <code class="highlight"><c- n>E1</c-></code> has a signed
type and non-negative value, and E1×2<sup>E2</sup> is representable in the
corresponding unsigned type of the result type, then that value, converted to
the result type, is the resulting value; otherwise, the behavior is
undefined.</del>
     <ins>2<sup>N</sup>, where <em>N</em> is the number of value
bits in the result type.</ins>
    </p>
    <p class="issue" id="issue-a7ff2cb6"><a class="self-link" href="#issue-a7ff2cb6"></a> updated to reflect poll "Left shift should be the same for signed and
unsigned".</p>
    <p>
     The value of <code class="highlight"><c- n>E1</c-> <c- o>>></c-> <c- n>E2</c-></code> is <code class="highlight"><c- n>E1</c-></code> right-shifted <code class="highlight"><c- n>E2</c-></code> bit positions. 
     <del>If <code class="highlight"><c- n>E1</c-></code> has an unsigned type or if <code class="highlight"><c- n>E1</c-></code> has a signed type and a non-negative value,
the</del>
     <ins>The</ins>
      value of the result is 
     <del>the integral part of the
quotient of <code class="highlight"><c- n>E1</c-><c- o>/</c-><c- mf>2</c-><sup><c- mf>E2</c-></sup></code>. If <code class="highlight"><c- n>E1</c-></code> has a signed type and a
negative value, the resulting value is implementation-defined.</del>
     <ins> <code class="highlight"><c- n>E1</c-> <c- o>/</c-> <c- mf>2</c-><sup><c- mf>E2</c-></sup></code>, rounded down. [<em>Note</em>: Right-shift on signed
integral types is an arithmetic right shift, which performs sign-extension.
—<em>end note</em>]</ins>
    </p>
   </blockquote>
   <p>Leave Constant expressions [<strong>expr.const</strong>] ❡2 as-is:</p>
   <blockquote>
    <p>An expression <code class="highlight"><c- n>e</c-></code> is a <em>core constant expression</em> unless the evaluation of <code class="highlight"><c- n>e</c-></code>,
following the rules of the abstract machine, would evaluate one of the following
expressions:</p>
    <p>[…]</p>
    <ul>
     <li data-md>
      <p>an operation that would have undefined behavior as specified in Clause 4
through 19 of this document [<em>Note</em>: including, for example, signed
integer overflow, certain pointer arithmetic, division
by zero, or certain shift operations —<em>end note</em>]</p>
    </ul>
   </blockquote>
   <p>Modify Enumeration declarations [<strong>dcl.enum</strong>] ❡8:</p>
   <blockquote>
    <p>
     For an enumeration whose underlying type is fixed, the values of the enumeration
are the values of the underlying type. Otherwise, for an enumeration where
e<sub>min</sub> is the smallest enumerator and e<sub>max</sub> is the largest,
the values of the enumeration are the values in the range b<sub>min</sub> to
b<sub>max</sub>, defined as follows: 
     <del>Let <em>K</em> be 1 for a two’s complement
representation and 0 for a ones' complement or sign-magnitude representation.</del>
      b<sub>max</sub> is the smallest value greater than or equal to
max(|e<sub>min</sub>| - 
     <del>K</del>
     <ins>1</ins>
     , |e<sub>max</sub>|) and equal to 2<sup>M</sup>-1,
where <em>M</em> is a non-negative integer. b<sub>min</sub> is zero if e<sub>min</sub> is non-negative and -(b<sub>max</sub>+
     <del>K</del>
     <ins>1</ins>
     ) otherwise. The size of the smallest
bit-field large enough to hold all the values of the enumeration type is
max(M,1) if b<sub>min</sub> is zero and M+1 otherwise. It is possible to define
an enumeration that has values not defined by any of its enumerators. If the <em>enumerator-list</em> is empty, the values of the enumeration are as if the
enumeration had a single enumerator with value 0.
    </p>
   </blockquote>
   <p>Leave <code class="highlight"><c- n>numeric_limits</c-></code> members [<strong>numeric.limits.members</strong>] ❡61 onwards as-is:</p>
   <blockquote>
<pre class="highlight"><c- k>static</c-> <c- k>constexpr</c-> <c- b>bool</c-> <c- n>is_modulo</c-><c- p>;</c-></pre>
    <p><code class="highlight">true</code> if the type is modulo. A type is modulo if, for any operation involving <code class="highlight"><c- o>+</c-></code>, <code class="highlight"><c- o>-</c-></code>, or <code class="highlight"><c- o>*</c-></code> on values of that type whose result would fall outside the
range <code class="highlight"><c- p>[</c-><c- n>min</c-><c- p>(),</c-> <c- n>max</c-><c- p>()]</c-></code>, the value returned differs from the true value by
an integer multiple of <code class="highlight"><c- n>max</c-><c- p>()</c-> <c- o>-</c-> <c- n>min</c-><c- p>()</c-> <c- o>+</c-> <c- mi>1</c-></code>.</p>
    <p>[<em>Example:</em><code class="highlight"><c- n>is_modulo</c-></code> is <code class="highlight">false</code> for signed integer types unless an
implementation, as an extension to this document, defines signed integer
overflow to wrap. —<em>end example</em>]</p>
    <p>Meaningful for all specializations.</p>
   </blockquote>
   <p>Modify Type properties [<strong>meta.unary.prop</strong>] ❡9 as follows:</p>
   <blockquote>
    <p>The predicate condition for a template specialization <code class="highlight"><c- n>has_unique_object_representations</c-><c- o>&lt;</c-><c- n>T</c-><c- o>></c-></code> shall be satisfied if and only if:</p>
    <ul>
     <li data-md>
      <p><code class="highlight"><c- n>T</c-></code> is trivially copyable, and</p>
     <li data-md>
      <p>any two objects of type <code class="highlight"><c- n>T</c-></code> with the same value have the same object
representation, where two objects of array or non-union class type are
considered to have the same value if their respective sequences of direct
subobjects have the same values, and two objects of union type are
considered to have the same value if they have the same active member and
the corresponding members have the same value.</p>
    </ul>
    <p>
     The set of scalar types for which this condition holds is implementation-defined.
[<em>Note:</em> If a type has padding bits, the condition does not hold; otherwise, the
condition holds true for 
     <ins><code class="highlight"><c- b>bool</c-></code>, signed, and </ins>
     unsigned integral types.
—<em>end note</em>]
    </p>
    <p class="issue" id="issue-7fbad8ee"><a class="self-link" href="#issue-7fbad8ee"></a> this was missing from P0907r0. Adding signed here seems like a
no-brainer. GCC and LLVM currently return <code class="highlight">true</code> for <code class="highlight"><c- b>bool</c-></code> (and it currently
isn’t implemented in MSVC). <a href="https://godbolt.org/g/pxaidA">Try it out</a>.</p>
   </blockquote>
   <p>Modify Class template <code class="highlight"><c- n>ratio</c-></code> [<strong>ratio.ratio</strong>] ❡1 as follows:</p>
   <blockquote>
    <p>
     If the template argument <code class="highlight"><c- n>D</c-></code> is zero or the absolute values of either of the
template arguments <code class="highlight"><c- n>N</c-></code> and <code class="highlight"><c- n>D</c-></code> is not representable by type <code class="highlight"><c- b>intmax_t</c-></code>, the
program is ill-formed. [<em>Note:</em> These rules ensure that infinite ratios are
avoided and that for any negative input, there exists a representable value of
its absolute value which is positive. 
     <del>In a two’s complement representation,
this</del>
     <ins>This</ins>
      excludes the most negative value. —<em>end note</em>]
    </p>
   </blockquote>
   <p>Modify Specializations for integers [<strong>atomics.types.int</strong>] ❡7 and ❡8 as
follows:</p>
   <blockquote>
    <p>
     <em>Remarks:</em> For signed integer types, 
     <del>arithmetic is defined to use two’s
complement representation. </del>
     <ins>the result is as if the object value and
parameters were converted to their corresponding unsigned types, the computation
performed on those types, and the result converted back to the signed type.
[<em>Note:</em> </ins>
      There are no undefined results
     <ins> arising from the computation.
—<em>end note</em>]</ins>
    </p>
    <p class="issue" id="issue-1c95a401"><a class="self-link" href="#issue-1c95a401"></a> the operations this applies to are add, or, and, sub, xor, and is only
meaningful for add and sub.</p>
<pre class="highlight"><c- n>T</c-> <c- k>operator</c-> <c- n>op</c-><c- o>=</c-><c- p>(</c-><c- n>T</c-> <c- n>operand</c-><c- p>)</c-> <c- k>volatile</c-> <c- k>noexcept</c-><c- p>;</c->
<c- n>T</c-> <c- k>operator</c-> <c- n>op</c-><c- o>=</c-><c- p>(</c-><c- n>T</c-> <c- n>operand</c-><c- p>)</c-> <c- k>noexcept</c-><c- p>;</c->
</pre>
    <p><em>Effects:</em> Equivalent to:</p>
    <del><code class="highlight"><c- k>return</c-> <c- nf>fetch_key</c-><c- p>(</c-><c- n>operand</c-><c- p>)</c-> <c- n>op</c-> <c- n>operand</c-><c- p>;</c-></code></del>
    <ins><code class="highlight"><c- k>return</c-> <c- k>static_cast</c-><c- o>&lt;</c-><c- n>T</c-><c- o>></c-><c- p>(</c-><c- k>static_cast</c-><c- o>&lt;</c-><c- n>make_unsigned_t</c-><c- o>&lt;</c-><c- n>T</c-><c- o>>></c-><c- p>(</c-><c- n>fetch_key</c-><c- p>(</c-><c- n>operand</c-><c- p>))</c-> <c- n>op</c-> <c- k>static_cast</c-><c- o>&lt;</c-><c- n>make_unsigned_t</c-><c- o>&lt;</c-><c- n>T</c-><c- o>>></c-><c- p>(</c-><c- n>operand</c-><c- p>));</c-></code></ins>
    <p class="issue" id="issue-9e580102"><a class="self-link" href="#issue-9e580102"></a> there’s an outstanding defect report for this <a data-link-type="biblio" href="#biblio-lwg3047">[LWG3047]</a>, whose
resolution should be updated as above.</p>
   </blockquote>
   <h2 class="heading settled" data-level="4" id="scope"><span class="secno">4. </span><span class="content">Out of Scope</span><a class="self-link" href="#scope"></a></h2>
   <p>This proposal focuses on the representation of signed integers, and on
tightening the specification when that representation is constrained to two’s
complement. It is out of scope for this proposal to deal with related issues
which have more to them than simply the representation of signed integers.</p>
   <p>A non-comprehensive list of items left purposefully out:</p>
   <ul>
    <li data-md>
     <p>Left and right shift with a right-hand-side equal to or wider than the
bit-width of the left-hand-side.</p>
    <li data-md>
     <p>Integral division or modulo by zero.</p>
    <li data-md>
     <p>Integral division or modulo of the signed minimum integral value for a
particular integral type by minus one.</p>
    <li data-md>
     <p>Overflow of pointer arithmetic.</p>
    <li data-md>
     <p>Library solution for ones' complement integers.</p>
    <li data-md>
     <p>Library solution for signed magnitude integers.</p>
    <li data-md>
     <p>Library solution for two’s complement integers with trapping or undefined
overflow semantics.</p>
    <li data-md>
     <p>Language support for explicit signed overflow truncation such as Swift’s
(<code class="highlight"><c- o>&amp;+</c-></code>, <code class="highlight"><c- o>&amp;-</c-></code>, and <code class="highlight"><c- o>&amp;*</c-></code>), or complementary trapping overflow operators.</p>
    <li data-md>
     <p>Library or language support for saturating arithmetic.</p>
    <li data-md>
     <p>Mechanism to let the compiler assume that integers, signed or unsigned, do
not experience signed or unsigned wrapping for:</p>
     <ul>
      <li data-md>
       <p>A specific integral variable.</p>
      <li data-md>
       <p>All integral variables (à la <code class="highlight"><c- o>-</c-><c- n>ftrapv</c-></code>, <code class="highlight"><c- o>-</c-><c- n>fno</c-><c- o>-</c-><c- n>wrapv</c-></code>, and <code class="highlight"><c- o>-</c-><c- n>fstrict</c-><c- o>-</c-><c- n>overflow</c-></code>).</p>
      <li data-md>
       <p>A specific loop’s induction variable.</p>
     </ul>
    <li data-md>
     <p>Mechanism to have the compiler list places where it could benefit from
knowing that overflow cannot occur (à la <code class="highlight"><c- o>-</c-><c- n>Wstrict</c-><c- o>-</c-><c- n>overflow</c-></code>).</p>
    <li data-md>
     <p>Endianness of integral storage (or endianness in general).</p>
    <li data-md>
     <p>Bits per bytes, though we all know there are eight.</p>
   </ul>
   <p>These items could be tackled in separate proposals, unless the committee wants
them tackled here. This paper expresses no preference in whether they should be
addressed or how.</p>
   <h2 class="heading settled" data-level="5" id="c-sign"><span class="secno">5. </span><span class="content">C Signed Integer Wording</span><a class="self-link" href="#c-sign"></a></h2>
   <p>The following is the wording on integers from the C11 Standard.</p>
   <blockquote>
    <p>For unsigned integer types other than unsigned char, the bits of the object
  representation shall be divided into two groups: value bits and padding bits
  (there need not be any of the latter). If there are <em>N</em> value bits, each bit
  shall represent a different power of 2 between 1 and 2<sup>N−1</sup>, so that
  objects of that type shall be capable of representing values from 0 to
  2<sup>N</sup> − 1 using a pure binary representation; this shall be known as
  the value representation. The values of any padding bits are unspecified.</p>
    <p>For signed integer types, the bits of the object representation shall be
  divided into three groups: value bits, padding bits, and the sign bit. There
  need not be any padding bits; <code class="highlight"><c- b>signed</c-> <c- b>char</c-></code> shall not have any padding bits.
  There shall be exactly one sign bit. Each bit that is a value bit shall have
  the same value as the same bit in the object representation of the
  corresponding unsigned type (if there are <em>M</em> value bits in the signed type
  and <em>N</em> in the unsigned type, then M ≤ N). If the sign bit is zero, it shall
  not affect the resulting value. If the sign bit is one, the value shall be
  modified in one of the following ways:</p>
    <ul>
     <li data-md>
      <p>the corresponding value with sign bit 0 is negated (<em>sign and magnitude</em>);</p>
     <li data-md>
      <p>the sign bit has the value −(2<sup>M</sup>) (<em>two’s complement</em>);</p>
     <li data-md>
      <p>the sign bit has the value −(2<sup>M</sup> − 1) (<em>ones’ complement</em>).</p>
    </ul>
    <p>Which of these applies is implementation-defined, as is whether the value with
  sign bit 1 and all value bits zero (for the first two), or with sign bit and
  all value bits 1 (for ones’ complement), is a trap representation or a normal
  value. In the case of sign and magnitude and ones’ complement, if this
  representation is a normal value it is called a <em>negative zero</em>.</p>
    <p>If the implementation supports negative zeros, they shall be generated only
  by:</p>
    <ul>
     <li data-md>
      <p>the <code class="highlight"><c- o>&amp;</c-></code>, <code class="highlight"><c- o>|</c-></code>, <code class="highlight"><c- o>^</c-></code>, <code class="highlight"><c- o>~</c-></code>, <code class="highlight"><c- o>&lt;&lt;</c-></code>, and <code class="highlight"><c- o>>></c-></code> operators with operands that produce such a value;</p>
     <li data-md>
      <p>the <code class="highlight"><c- o>+</c-></code>, <code class="highlight"><c- o>-</c-></code>, <code class="highlight"><c- o>*</c-></code>, <code class="highlight"><c- o>/</c-></code>, and <code class="highlight"><c- o>%</c-></code> operators where one operand is a negative zero and the result is zero;</p>
     <li data-md>
      <p>compound assignment operators based on the above cases.</p>
    </ul>
    <p>It is unspecified whether these cases actually generate a negative zero or a
  normal zero, and whether a negative zero becomes a normal zero when stored in
  an object.</p>
    <p>If the implementation does not support negative zeros, the behavior of the <code class="highlight"><c- o>&amp;</c-></code>, <code class="highlight"><c- o>|</c-></code>, <code class="highlight"><c- o>^</c-></code>, <code class="highlight"><c- o>~</c-></code>, <code class="highlight"><c- o>&lt;&lt;</c-></code>, and <code class="highlight"><c- o>>></c-></code> operators with operands that would produce
  such a value is undefined.</p>
    <p>The values of any padding bits are unspecified. A valid (non-trap) object
  representation of a signed integer type where the sign bit is zero is a valid
  object representation of the corresponding unsigned type, and shall represent
  the same value. For any integer type, the object representation where all the
  bits are zero shall be a representation of the value zero in that type.</p>
    <p>The <em>precision</em> of an integer type is the number of bits it uses to represent
  values, excluding any sign and padding bits. The <em>width</em> of an integer type is
  the same but including any sign bit; thus for unsigned integer types the two
  values are the same, while for signed integer types the width is one greater
  than the precision.</p>
   </blockquote>
   <h2 class="heading settled" data-level="6" id="survey"><span class="secno">6. </span><span class="content">Survey of Signed Integer Representations</span><a class="self-link" href="#survey"></a></h2>
   <p>Here is a non-comprehensive history of signed integer representations:</p>
   <ul>
    <li data-md>
     <p>Two’s complement</p>
     <ul>
      <li data-md>
       <p>John von Neumann suggested use of two’s complement binary representation in his 1945 First Draft of a Report on the EDVAC proposal for an electronic stored-program digital computer.</p>
      <li data-md>
       <p>The 1949 EDSAC, which was inspired by the First Draft, used two’s complement representation of binary numbers.</p>
      <li data-md>
       <p>Early commercial two’s complement computers include the Digital Equipment Corporation PDP-5 and the 1963 PDP-6.</p>
      <li data-md>
       <p>The System/360, introduced in 1964 by IBM, then the dominant player in the computer industry, made two’s complement the most widely used binary representation in the computer industry.</p>
      <li data-md>
       <p>The first minicomputer, the PDP-8 introduced in 1965, uses two’s complement arithmetic as do the 1969 Data General Nova, the 1970 PDP-11.</p>
     </ul>
    <li data-md>
     <p>Ones' complement</p>
     <ul>
      <li data-md>
       <p>Many early computers, including the CDC 6600, the LINC, the PDP-1, and the UNIVAC 1107.</p>
      <li data-md>
       <p>Successors of the CDC 6600 continued to use ones' complement until the late 1980s.</p>
      <li data-md>
       <p>Descendants of the UNIVAC 1107, the UNIVAC 1100/2200 series, continue to do so, although ClearPath machines are a common platform that implement either the 1100/2200 architecture (the ClearPath IX series) or the Burroughs large systems architecture (the ClearPath NX series). Everything is common except the actual CPUs, which are implemented as ASICs. In addition to the IX (1100/2200) CPUs and the NX (Burroughs large systems) CPU, the architecture had Xeon (and briefly Itanium) CPUs. Unisys' goal was to provide an orderly transition for their 1100/2200 customers to a more modern architecture.</p>
     </ul>
    <li data-md>
     <p>Signed magnitude</p>
     <ul>
      <li data-md>
       <p>The IBM 700/7000 series scientific machines use sign/magnitude notation, except for the index registers which are two’s complement.</p>
     </ul>
   </ul>
   <p><a href="https://en.wikipedia.org/wiki/Two%27s_complement">Wikipedia</a> offers
more details and has comprehensive sources for the above.</p>
   <p>Thomas Rodgers surveyed popular DSPs and found the following:</p>
   <ul>
    <li data-md>
     <p>SHARC family ships <a href="http://www.analog.com/media/en/dsp-documentation/software-manuals/cces-SharcCompiler-manual.pdf">a C++ compiler</a> which supports C++11, and where signed integers are two’s complement.</p>
    <li data-md>
     <p>Freescale/NXP ships <a href="https://www.nxp.com/docs/en/reference-manual/SC_COMPILER_USERS_GUIDE.pdf">a C++ compiler</a> which supports C++03, and where signed integers are two’s complement
(<a href="https://www.nxp.com/docs/en/reference-manual/MNSC140CORE.pdf">reference</a>).</p>
    <li data-md>
     <p>Texas Instruments ships <a href="http://www.ti.com/lit/ug/slau132r/slau132r.pdf">a C++ compiler</a> which
supports C++14, and where signed integers are two’s complement.</p>
    <li data-md>
     <p><a href="https://www.cirrus.com/products/cs4970xx/">Cirrus Logic</a> (formerly Wolfson)
has <a href="https://d3uzseaevmutz1.cloudfront.net/pubs/manual/cirrus_c_compiler_um15.pdf">a C compiler only</a> which is probably two’s complement.</p>
    <li data-md>
     <p>CML Microcircuits has fixed ASIC for radio processing, and doesn’t seem to
support C++.</p>
    <li data-md>
     <p>Synaptics (formerly Connexant) makes audio input subsystem for voice
assistants. The DSP runs fixed far-field signal processing algorithms and
has programmable functions which run on standard ARM controller, using
Raspbian.</p>
   </ul>
   <p>In short, the only machine the author could find using non-two’s complement are
made by Unisys, and no counter-example was brought by any member of the C++
standards committee. Nowadays Unisys emulates their old architecture using x86
CPUs with attached FPGAs for customers who have legacy applications which
they’ve been unable to migrate. These applications are unlikely to be well
served by modern C++, signed integers are the least of their
problem. Post-modern C++ should focus on serving its existing users well, and
incoming users should be blissfully unaware of integer esoterica.</p>
   <h2 class="heading settled" data-level="7" id="WG14"><span class="secno">7. </span><span class="content">WG14 Feedback from the Brno Meeting</span><a class="self-link" href="#WG14"></a></h2>
   <p>WG14 met in Brno to discuss <a data-link-type="biblio" href="#biblio-n2218">[N2218]</a>. The paper was received very positively,
especially given that no one in the room knew of an extant architecture that was
not two’s complement for which there was a reasonably modern C compiler. The
closest anyone came was the Unisys ClearPath compiler documentation which says:</p>
   <blockquote>
    <p>Two’s complement arithmetic is used on many platforms. On ClearPath MCP
  systems, arithmetic is performed on data in signed-magnitude form. This can
  cause discrepancies in algorithms that depend on the two’s complement
  representation.</p>
   </blockquote>
   <p>However, this compiler documentation also says that they only target
C90, and was last updated on 2017.</p>
   <p>There was worry about the search on impacted architectures not having been
exhaustive. Given that WG14 will ship the IS in 5 years, it was felt that making
them aware now should give vendors plenty of time to bring up reasons why this
change would be bad for them.</p>
   <p>It was pointed out that C already has cases that require two’s complement.</p>
   <p>It was noted that the existing implementation latitude is a burden for library
developers because they have to consider test cases where integers are not two’s
complement but they have no way to actually exercise any of those test cases.</p>
   <p>The following straw poll was taken:</p>
   <table class="def">
    <tbody>
     <tr>
      <th style="width: 70%;">
      <th><strong>F</strong>
      <th><strong>N</strong>
      <th><strong>A</strong>
     <tr>
      <th><small>Remove (not deprecate) non-two’s complement representations for signed integers.</small>
      <th>14
      <th>0
      <th>3
   </table>
  </main>
<script>
(function() {
  "use strict";
  var collapseSidebarText = '<span aria-hidden="true">←</span> '
                          + '<span>Collapse Sidebar</span>';
  var expandSidebarText   = '<span aria-hidden="true">→</span> '
                          + '<span>Pop Out Sidebar</span>';
  var tocJumpText         = '<span aria-hidden="true">↑</span> '
                          + '<span>Jump to Table of Contents</span>';

  var sidebarMedia = window.matchMedia('screen and (min-width: 78em)');
  var autoToggle   = function(e){ toggleSidebar(e.matches) };
  if(sidebarMedia.addListener) {
    sidebarMedia.addListener(autoToggle);
  }

  function toggleSidebar(on) {
    if (on == undefined) {
      on = !document.body.classList.contains('toc-sidebar');
    }

    /* Don’t scroll to compensate for the ToC if we’re above it already. */
    var headY = 0;
    var head = document.querySelector('.head');
    if (head) {
      // terrible approx of "top of ToC"
      headY += head.offsetTop + head.offsetHeight;
    }
    var skipScroll = window.scrollY < headY;

    var toggle = document.getElementById('toc-toggle');
    var tocNav = document.getElementById('toc');
    if (on) {
      var tocHeight = tocNav.offsetHeight;
      document.body.classList.add('toc-sidebar');
      document.body.classList.remove('toc-inline');
      toggle.innerHTML = collapseSidebarText;
      if (!skipScroll) {
        window.scrollBy(0, 0 - tocHeight);
      }
      tocNav.focus();
      sidebarMedia.addListener(autoToggle); // auto-collapse when out of room
    }
    else {
      document.body.classList.add('toc-inline');
      document.body.classList.remove('toc-sidebar');
      toggle.innerHTML = expandSidebarText;
      if (!skipScroll) {
        window.scrollBy(0, tocNav.offsetHeight);
      }
      if (toggle.matches(':hover')) {
        /* Unfocus button when not using keyboard navigation,
           because I don’t know where else to send the focus. */
        toggle.blur();
      }
    }
  }

  function createSidebarToggle() {
    /* Create the sidebar toggle in JS; it shouldn’t exist when JS is off. */
    var toggle = document.createElement('a');
      /* This should probably be a button, but appearance isn’t standards-track.*/
    toggle.id = 'toc-toggle';
    toggle.class = 'toc-toggle';
    toggle.href = '#toc';
    toggle.innerHTML = collapseSidebarText;

    sidebarMedia.addListener(autoToggle);
    var toggler = function(e) {
      e.preventDefault();
      sidebarMedia.removeListener(autoToggle); // persist explicit off states
      toggleSidebar();
      return false;
    }
    toggle.addEventListener('click', toggler, false);


    /* Get <nav id=toc-nav>, or make it if we don’t have one. */
    var tocNav = document.getElementById('toc-nav');
    if (!tocNav) {
      tocNav = document.createElement('p');
      tocNav.id = 'toc-nav';
      /* Prepend for better keyboard navigation */
      document.body.insertBefore(tocNav, document.body.firstChild);
    }
    /* While we’re at it, make sure we have a Jump to Toc link. */
    var tocJump = document.getElementById('toc-jump');
    if (!tocJump) {
      tocJump = document.createElement('a');
      tocJump.id = 'toc-jump';
      tocJump.href = '#toc';
      tocJump.innerHTML = tocJumpText;
      tocNav.appendChild(tocJump);
    }

    tocNav.appendChild(toggle);
  }

  var toc = document.getElementById('toc');
  if (toc) {
    createSidebarToggle();
    toggleSidebar(sidebarMedia.matches);

    /* If the sidebar has been manually opened and is currently overlaying the text
       (window too small for the MQ to add the margin to body),
       then auto-close the sidebar once you click on something in there. */
    toc.addEventListener('click', function(e) {
      if(e.target.tagName.toLowerCase() == "a" && document.body.classList.contains('toc-sidebar') && !sidebarMedia.matches) {
        toggleSidebar(false);
      }
    }, false);
  }
  else {
    console.warn("Can’t find Table of Contents. Please use <nav id='toc'> around the ToC.");
  }

  /* Wrap tables in case they overflow */
  var tables = document.querySelectorAll(':not(.overlarge) > table.data, :not(.overlarge) > table.index');
  var numTables = tables.length;
  for (var i = 0; i < numTables; i++) {
    var table = tables[i];
    var wrapper = document.createElement('div');
    wrapper.className = 'overlarge';
    table.parentNode.insertBefore(wrapper, table);
    wrapper.appendChild(table);
  }

})();
</script>
  <h2 class="no-num no-ref heading settled" id="references"><span class="content">References</span><a class="self-link" href="#references"></a></h2>
  <h3 class="no-num no-ref heading settled" id="informative"><span class="content">Informative References</span><a class="self-link" href="#informative"></a></h3>
  <dl>
   <dt id="biblio-c11">[C11]
   <dd><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf">Programming Languages — C</a>. URL: <a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf">http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf</a>
   <dt id="biblio-gcc">[GCC]
   <dd><a href="https://gcc.gnu.org/onlinedocs/gcc/Integers-implementation.html">GCC C Implementation-Defined Behavior: Integers</a>. URL: <a href="https://gcc.gnu.org/onlinedocs/gcc/Integers-implementation.html">https://gcc.gnu.org/onlinedocs/gcc/Integers-implementation.html</a>
   <dt id="biblio-llvm">[LLVM]
   <dd><a href="https://llvm.org/docs/LangRef.html">LLVM Language Reference Manual</a>. URL: <a href="https://llvm.org/docs/LangRef.html">https://llvm.org/docs/LangRef.html</a>
   <dt id="biblio-lwg3047">[LWG3047]
   <dd>Tim Song. <a href="https://wg21.link/lwg3047">atomic compound assignment operators can cause undefined behavior when corresponding fetch_meow members don't</a>. New. URL: <a href="https://wg21.link/lwg3047">https://wg21.link/lwg3047</a>
   <dt id="biblio-msvc">[MSVC]
   <dd><a href="https://docs.microsoft.com/en-us/cpp/c-language/integers">MSVC C Implementation-Defined Behavior: Integers</a>. URL: <a href="https://docs.microsoft.com/en-us/cpp/c-language/integers">https://docs.microsoft.com/en-us/cpp/c-language/integers</a>
   <dt id="biblio-n2218">[N2218]
   <dd>JF Bastien. <a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2218.html">Signed integers are two's complement</a>. URL: <a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2218.html">http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2218.html</a>
   <dt id="biblio-p0907r0">[P0907r0]
   <dd>JF Bastien. <a href="https://wg21.link/p0907r0">Signed Integers are Two’s Complement</a>. 9 February 2018. URL: <a href="https://wg21.link/p0907r0">https://wg21.link/p0907r0</a>
   <dt id="biblio-taocp">[TAoCP]
   <dd>Donald Knuth. The Art of Computer Programming, Volume 2 (3rd Ed.): Seminumerical Algorithms. 
  </dl>
  <h2 class="no-num no-ref heading settled" id="issues-index"><span class="content">Issues Index</span><a class="self-link" href="#issues-index"></a></h2>
  <div style="counter-reset:issue">
   <div class="issue"> We need to define the storage for <code class="highlight"><c- b>bool</c-></code> since we define signed and
unsigned below, and that excludes <code class="highlight"><c- b>bool</c-></code>. The definition I propose is more
restrictive than what we had before because it only allows two values to be
represented, and doesn’t allow padding bits. This guarantees that <code class="highlight"><c- b>bool</c-></code> is
trivially-copyable, and gives it a unique object representation, which as far as
I know all compilers already guaranteed.<a href="#issue-540ad40f"> ↵ </a></div>
   <div class="issue"> An intermediate revision of this paper stated "Value bits are store
contiguously in memory" in an attempt to preserve different endiannesses, and
otherwise restricts implementations to "sane" layout. However, that change
wasn’t presented to EWG and received pushback on the SG6 reflector. Would this
be a desirable addition, should it be in a separate paper, or does it
overconstrain implementations?<a href="#issue-28d91b9b"> ↵ </a></div>
   <div class="issue"> note <em>M = N-1</em>, whereas C says <em>M ≤ N</em>. I derive this from "For each of
the standard signed integer types, there exists a corresponding (but different)
standard unsigned integer type [...] <strong>each of which occupies the same
amount of storage</strong>".<a href="#issue-5bda07bf"> ↵ </a></div>
   <div class="issue"> In C11 implementation requirements call it the "extraordinary value" and
refer to 6.2.6.2 which calls it "is a trap representation or a normal
value". Furthermore, in note 53 there’s wording around extraordinary values
being held in padding bits (not just as a value stolen from the value
representation), and since C++ wording used to only talk about "binary
representation" it’d rather be very clear about the absence of extraordinary
values. It’s unclear whether SG6 / SG12 guidance explicitly wanted to disallow
padding bits from being special and trapping. I propose disallowing it.<a href="#issue-83f525f6"> ↵ </a></div>
   <div class="issue"> the above change is for enumeration <em>to</em> integer, which SG6 did not
object to changing as suggested. It states the conversion in terms of the
updated [<strong>conv.integral</strong>] rules.<a href="#issue-1a4cd6e3"> ↵ </a></div>
   <div class="issue"> the above unmodified paragraph is for integer <em>to</em> enumeration which SG6
voted to leave undefined in poll "Cast to enums outside of the enum’s
representable range should be defined instead of undefined behavior".<a href="#issue-0a0c2243"> ↵ </a></div>
   <div class="issue"> updated to reflect poll "Left shift should be the same for signed and
unsigned".<a href="#issue-a7ff2cb6"> ↵ </a></div>
   <div class="issue"> this was missing from P0907r0. Adding signed here seems like a
no-brainer. GCC and LLVM currently return <code class="highlight">true</code> for <code class="highlight"><c- b>bool</c-></code> (and it currently
isn’t implemented in MSVC). <a href="https://godbolt.org/g/pxaidA">Try it out</a>.<a href="#issue-7fbad8ee"> ↵ </a></div>
   <div class="issue"> the operations this applies to are add, or, and, sub, xor, and is only
meaningful for add and sub.<a href="#issue-1c95a401"> ↵ </a></div>
   <div class="issue"> there’s an outstanding defect report for this <a data-link-type="biblio" href="#biblio-lwg3047">[LWG3047]</a>, whose
resolution should be updated as above.<a href="#issue-9e580102"> ↵ </a></div>
  </div>